From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Why is SERIAL a keyword? |
Date: | 2001-08-15 14:19:12 |
Message-ID: | 25848.997885152@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I was just looking at adding SERIAL4 and SERIAL8 pseudo-types to the
system, per our previous discussion, and I started to wonder why SERIAL
is treated as a keyword by the grammar. Wouldn't it be better to remove
that keyword and allow the grammar to parse "serial" as a type name?
Then analyze.c would just do a strcmp on the type name to see if it's
"serial" (or one of the new variants) before trying to look it up in
pg_type.
The only downside I can see to this is that it's currently possible to
use a user-defined type named "serial", if you are determined enough:
create table foo (
f1 serial, -- it's a serial column
f2 "serial", -- user-defined type named "serial"
This would stop working with my proposed approach. But it seems pretty
ugly and fragile anyway; is it likely that anyone's doing this?
A variant idea is for analyze.c to check for "serial" etc. only if
lookup of the type name fails. This would mean that one could actually
override the system definitions of "serial" etc. by creating
user-defined types with these names. I'm quite unconvinced that that
would be a good idea, but if anyone wants to argue for it...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2001-08-15 14:28:35 | Re: encoding names |
Previous Message | Tom Lane | 2001-08-15 13:58:08 | Re: convert function |