Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)
Date
Msg-id 14322.951940687@sss.pgh.pa.us
Whole thread Raw
In response to Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)  (Peter Eisentraut <e99re41@DoCS.UU.SE>)
Responses Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
> NOOOOOOOOOOOOOO. I'm not trying to treat "bit varying" as a special case
> name. I want to treat it as a normal name. There's absolutely no
> difference whether the pg_type entry for the type represented by the
> tokens BIT VARYING is "varbit", "bit varying", or "foo". I'm just saying
> that the second would be more obvious and convenient, but that it would
> require a small fix somewhere.

OK, fair enough, but the thing is: is the bootstrap parser the only
place that will have to be changed to make this possible?  I doubt it.
The fix may not be as small as you expect.

There's another issue, which is that the routines that implement
operations for a particular type are generally named after the type's
internal name.  I trust you are not going to propose that we find a way
to put spaces into C function names ;-).  It seems to me that the
confusion created by having support code named differently from the
type's internal name is just as bad as having the internal name
different from the external name.

This being the case, it seems like "bit_varying" might be a reasonable
compromise for the internal name, and that should work already...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Willy De la Court
Date:
Subject: empty dates and changing the default date behaviour
Next
From: Hannu Krosing
Date:
Subject: Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)