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: | BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST) |
Date: | 2000-03-01 15:52:07 |
Message-ID: | 1213.951925927@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:
> All I'm saying is that we add
> | BIT VARYING { $$ = "bit varying"; }
> No problem so far, right? Especially, if this is dumped out, then it
> becomes bit varying without any extra effort.
Well, no, it becomes "bit varying", *with* quotes, if the dumper is
not broken. (Unless we special-case the dumper to know that this
particular typename doesn't need to be quoted despite its embedded
space --- but that's what you hoped to avoid.) So there's no automatic
way of producing a completely SQL-compliant dump for this type name,
and that removes what would otherwise be (IMHO) the strongest argument
for making the internal name be "bit varying" and not "varbit" or
whatever.
A much more significant problem for this particular datatype is that it
requires special syntax regardless, namely a length spec like the ones
for char and varchar:
<bit string type> ::=
BIT [ <left paren> <length> <right paren> ]
| BIT VARYING <left paren> <length> <right paren>
Currently, char and numeric (the existing types that need length
specifications) have to be special-cased everywhere in order to
parse or append the length info. I foresee the same will be needed
for bit and bit varying. If you can find a way to avoid
that special-case logic, I'll get a lot more excited about not
having to treat "bit varying" as a special-case name.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Horák Daniel | 2000-03-01 16:01:10 | PostgreSQL on Solaris/SPARC with gcc |
Previous Message | Karel Zak - Zakkr | 2000-03-01 15:44:49 | Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE |