From: | Böszörményi Zoltán <zboszor(at)dunaweb(dot)hu> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Extended SERIAL parsing |
Date: | 2006-06-12 12:27:31 |
Message-ID: | 4028.213.163.11.81.1150115251.squirrel@www.dunaweb.hu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Zoltan Boszormenyi <zboszor(at)dunaweb(dot)hu> writes:
>> after some experimentation, I came up with the attached patch,
>> which implements parsing the following SERIAL types:
>
> As has been pointed out before, it would be a seriously bad idea to
> implement the SQL syntax for identity columns without matching the
> SQL semantics for them. That would leave us behind the eight-ball
> when we wanted to implement the SQL semantics. Right now we have
> a useful but non-standard semantics, and a useful but non-standard
> syntax, and those two should stick together.
Well, I read all sections of 5WD-02-Foundation-2003-09.pdf
where "identity" appears, here are the list of changes that will
be needed for an identity column:
- Only one identity column can appear in the column list.
I have to check for this at CREATE, TABLE, ALTER TABLE ADD COLUMN
and ALTER TABLE ALTER COLUMN.
- ALTER TABLE ALTER COLUMN ... RESTART [WITH] or SET
alter the sequence on the column.
- If colname is SERIAL GENERATED ALWAYS, then
only "UPDATE SER colname = default" may occur.
Then there's the DROP default question: should PostgreSQL
allow it or not? What I found about this in the standard is this:
definitions of the DEFAULT clause, the identity column specification
and the generation clause are mutually exclusive, see 11.4.
So, if you cannot specify a DEFAULT for an identity column,
you must not be able to drop it, although this isn't expressed
in the standard, it's just my opinion.
Is there anything else? I haven't found any.
Or I can't read between the lines, which is a skill
that isn't required for reading standards. :-)
> I'm not too happy with converting SERIAL4 and SERIAL8 into reserved
> words, either, as I believe this patch does.
Not really, only IDENTITY is added to the list of reserved words,
serial/serial4/serial8/bigserial are just type names:
# create table serial8 (serial8 serial8 primary key);
NOTICE: CREATE TABLE will create implicit sequence "serial8_serial8_seq"
for serial column "serial8.serial8"
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"serial8_pkey" for table "serial8"
CREATE TABLE
The others (AS, GENERATED) were added to the
non-reserved keyword list.
> Some other things missing are documentation and pg_dump support.
I am working on that. The documentation is easier. :-)
Also note, that I misread the generated column syntax as part of the
identity column syntax. So, the parsing should only recognize
SERIAL [ GENERATED { ALWAYS | BY DEFAULT }
AS IDENTITY [ ( sequence_options ) ] ]
which I already fixed here and the sequence_options list
cannot be empty as with my previous attempt.
Best regards,
Zoltán Böszörményi
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2006-06-12 12:49:00 | Re: TODO: Add pg_get_acldef(), pg_get_typedefault(), |
Previous Message | Dave Page | 2006-06-12 11:13:45 | Re: pg_get_INDEXdef - opclass |