Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)
От | Tom Lane |
---|---|
Тема | Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST) |
Дата | |
Msg-id | 14322.951940687@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST) (Peter Eisentraut <e99re41@DoCS.UU.SE>) |
Ответы |
Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)
Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST) |
Список | 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 по дате отправления: