On Wed, 1 Mar 2000, Tom Lane wrote:
> Right. I think what Peter is actually suggesting is that BIT VARYING
> (which must be special-cased in gram.y) could be equivalent to
> "bit varying" (as a quoted identifier, that works already in most
> places, and arguably should work everywhere). There's a certain amount
> of intellectual cleanliness in that.
{Grin} That's exactly what I wanted.
> OTOH, it's not apparent that it's really any *better* than `varbit' or
> your choice of other space-free internal names.
It's better because then you don't need any special casing when you
provide the type back to the client. And it's better because you don't
need to remember that "foo" is really "bar" internally. And it's better
because it wouldn't disallow users from defining "varbit" themselves with
the non-obvious error message that it already exists. (Okay, the last is a
weak reason, but it is one.) Finally, it's better because it already
works, with only a minor change in the bootstrap scanner necessary.
> If SQL92 were a moving target then I'd be concerned about having to
> track the special cases in a lot of bits of code ... but it's not
> a moving target.
But PostgreSQL is a moving target in all regards. Where would you want to
do the endless internal/external type conversions on the way to the
client. In pg_dump? In psql? In libpq? In the server communications code?
Make a view around pg_type? How about nowhere and we just do the above?
Special cases suck. ;)
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
