Re: [SQL] An easy question about creating a primary key - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [SQL] An easy question about creating a primary key
Date
Msg-id 21442.1007433620@sss.pgh.pa.us
Whole thread Raw
In response to Re: [SQL] An easy question about creating a primary key  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [SQL] An easy question about creating a primary key  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
List pgsql-hackers
Now that I look at it, I think I made the relevant changes in the
parser:

2001-10-11 20:07  tgl
* doc/src/sgml/ref/alter_table.sgml, src/backend/catalog/pg_type.c,src/backend/commands/command.c,
src/backend/parser/analyze.c,src/backend/tcop/utility.c,
src/include/commands/command.h,src/include/nodes/parsenodes.h,src/test/regress/expected/alter_table.out,src/test/regress/expected/foreign_key.out:
BreaktransformCreateStmt()into multiple routines and maketransformAlterStmt() use these routines, instead of having
lotsofduplicate (not to mention should-have-been-duplicate) code.  Addinga column with a CHECK constraint actually
worksnow, and the teststo reject unsupported DEFAULT and NOT NULL clauses actually firenow.  ALTER TABLE ADD PRIMARY
KEYworks, modulo having to havecreated the column(s) NOT NULL already.
 

I was mainly interested in eliminating the inconsistencies in parse-time
handling of CREATE TABLE and ALTER TABLE, and the ensuing bugs mentioned
in the commit log.  I didn't think much about the possibility that I was
obsoleting stuff in command.c, but maybe I did.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [SQL] An easy question about creating a primary key
Next
From: Tom Lane
Date:
Subject: Re: [SQL] An easy question about creating a primary key