> > >> insert OID = 9999 ( bit varying PGUID 1 1 ...
> > The space in the type name is gonna confuse things.
> > AFAICS the solution would have to be similar to what we already do for
> > CHARACTER VARYING: parse the type declaration specially in gram.y,
> > and translate it to an internal type name.
> Those are only workarounds on the backend level though. Every new hack
> like this will require fixing every client applicatiion to translate that
> type right. It's fine with CHARACTER VARYING, because VARCHAR is an
> official alias (although it's not the real type name, mind you), but there
> is no VARBIT or NVARCHAR. It seems that allowing something like
> bit\ varying
> in the bootstrap scanner will solve the problem where it's being caused.
> Internal type names should go away, not accumulate. ;)
I'm not sure that I agree that multi-word character types are required
internally. Somehow that seems to just push the problem of
SQL92-specific syntax to another part of the code. We could just as
easily (?) translate *every* "xxx VARYING" to "varxxx" on input, and
do the inverse on output or pg_dump.
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2000-02-28 09:10:59|
|Subject: Re: [HACKERS] A further thought on rule string size|
|Previous:||From: Jose Soares||Date: 2000-02-28 08:44:57|
|Subject: Re: [GENERAL] AW: [HACKERS] TRANSACTIONS|