> > >> 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
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California