[DB-SIG] Type code mappings: expanding the type objects
Federico Di Gregorio
fog at initd.org
Thu Jan 8 06:35:49 EST 2004
Il gio, 2004-01-08 alle 12:23, Kevin Jacobs ha scritto:
> On Thu, 8 Jan 2004, Federico Di Gregorio wrote:
>
> > another list, amended with marc's comments. if everybody agrees on this
> > list i'll go on and write the new paragraph for the PEP document.
> >
> > changes:
> >
> > 1/ removed TEXT in favor of LONGVARCHAR;
>
> Just call it TEXT -- it really isn't a VARCHAR in most regards.
if no backend has both and honore the difference it is just a naming
convention. i would better like to have semi-standard LONGVARCHAR and
LONGBINARY than TEXT, BLOB, GLOB, etc.
> > 2/ removed MONEY (DECIMAL is the name for fixed point), backends
> > providing currency information will define a sub-type of decimal,
> > right?
>
> I'd keep it for now, even if it is vestigial. There are a lot of other
> backends that honor the difference.
did not know. i'll put MONEY back.
> > 3/ BOOLEAN is under NUMBER (this will probably give some problems to
> > postgresql and other db using 't' and 'f' but there is really no
> > simple solution and Python *do* use 1 and 0 for True and False (at
> > least untill 2.3)
>
> SQL 92 and 99 are very clear that booleans and integers are not
> interchangeable. The Python semantics should not be the driving factor
> here.
did not know about that too. we need a poll here, to see where every
module puts booleans right now. if there are enough differences we can
just have a new top-level class (and maybe let individual modules keep
the old meaning too; i see no problems with type_code x comparing true
both to BOOLEAN and NUMERIC).
> > i tought about using three or four levels:
> >
> > STRING
> > |__VARCHAR
> > |__LONGVARCHAR
> >
> > but i really don't see any improvement. the two-level hierarchy is there
> > for _backward compatibility_, not for organizing the tree. does this
> > make sense?
>
> The more compelling reason for a deeper hierarchy is so that type code
> matching can take place at several levels. i.e., some applications are
> satisfied to know that a datum is a string, while others will wish to decode
> the type information more deeply, but maybe not to the most derived type.
> e.g., many apps may be satisfied to know that a datum is a DECIMAL type, but
> not care enough to check if it is a MONEY type.
this is good example because MONEY is clearly more specific than
DECIMAL. but i dubt i can say that TEXT is more specific than VARCHAR or
that VARCHAR is more specific than text. mm.. if by "more specific" we
mean "can be casted to without loss of information" then a VARCHAR is
more specific...
> > here is the list:
> >
> > STRING
> > |__CHAR
> > |__VARCHAR
> > |__LONGVARCHAR
> > |__TEXT
> > |__WCHAR
> > |__WVARCHAR
> > |__WLONGVARCHAR
>
> I'm somewhat sceptical about the WCHAR versions of STRING types. Python has
> native support for unicode strings, so why maintain this artificial
> distinction? The better solution would be to augment the column description
> format to include character encoding information.
i wholehartly support the additiong of an encoding field to
.description.
> > BINARY
> > |__VARBINARY
> > |__LONGVARBINARY
> > NUMBER
> > |__BIT
> > |__INTEGER
> > |__SMALLINT
> > |__BIGINT
> > |__FLOAT
> > |__DOUBLE
> > |__REAL
> > |__DECIMAL
> > |__COMPLEX
> > |__BOOLEAN
> > DATETIME
> > |__DATE
> > |__TIME
> > |__TIMESTAMP
> > |__INTERVAL
> > |__TZTIME
> > |__TZTIMESTAMP
>
> Recent SQL standards put the TZ at the end, last I checked.
so let's follow the standard. :)
i'll wait for some more comments and send a new tree soon.
federico
p.s. do you people like list+cc postings? i can easily avoid... :)
--
Federico Di Gregorio http://people.initd.org/fog
Debian GNU/Linux Developer fog at debian.org
INIT.D Developer fog at initd.org
La felicità è una tazza di cioccolata calda. Sempre. -- Io
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Url : http://mail.python.org/pipermail/db-sig/attachments/20040108/5b032a2c/attachment.bin
More information about the DB-SIG
mailing list