From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST) |
Date: | 2000-03-01 19:58:07 |
Message-ID: | 14322.951940687@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <e99re41(at)DoCS(dot)UU(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2000-03-01 20:13:20 | Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0) |
Previous Message | Ross J. Reedstrom | 2000-03-01 19:30:14 | SQL92 standard corrections |