Skip site navigation (1) Skip section navigation (2)

Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

From: Don Baccus <dhogaza(at)pacifier(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jan Wieck <wieck(at)debis(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
Date: 2000-02-29 00:31:41
Message-ID: 3.0.1.32.20000228163141.00ecb4f0@mail.pacifier.com (view raw or flat)
Thread:
Lists: pgsql-hackers
At 06:25 PM 2/28/00 -0500, Tom Lane wrote:

>The other alternative that was discussed was to put the onus on
>analyze.c to fix things up.  Basically, we could make NOT DEFERRABLE
>and the other subclauses of foreign key clauses be independent
>clauses from the grammar's point of view;

Which, of course, they are in the SQL92 grammar...

> that is,
>
>	FOREIGN KEY blah blah NOT DEFERRABLE INITIALLY IMMEDIATE
>
>would be parsed as three separate constraint clauses producing three
>separate nodes in the column's constraint list.  Then analyze.c would
>make a pre-pass over the list to mark the FOREIGN KEY clause with the
>right values and remove the extraneous clauses.  (And to complain if
>any of them are not in the right place, of course.)

I just got back from my little coffee break spent reading the relevant bit
of gram.y, and after looking at the gyrations Thomas went through in his
patch I'm even more convinced that doing it "right" is not only right,
but in the long run simpler.

I think gram.y can be patched up to fix some of the more obvious 
missing cases but it will make it even messier than it is now.  And
it's already extremely messy.

Again, I'm sympathetic to Thomas because I tried to find a quick and
dirty work-around to Jan's original shift-reduce conflict several
weeks ago, without success.  Thomas' change isn't quick and dirty,
but rather complicated and messy and incomplete, but short of doing
it "right" (i.e. as Tom explains above) there's no other way I can
see.

Other than stepping outside the parser, so to speak, to do token
lookahead or to do a lexer kludge.  But these kludges only fix
Jan's original problem - and Jan's original grammar isn't SQL92
compliant...

>I don't recall whether Thomas liked that idea either ;-), but I'm coming
>around to the opinion that it's the best solution.

Well, the current effort tries to avoid the general case by listing
a bunch of possible combinations, which really doesn't feel right.



- Don Baccus, Portland OR <dhogaza(at)pacifier(dot)com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

In response to

pgsql-hackers by date

Next:From: Don BaccusDate: 2000-02-29 00:36:07
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
Previous:From: Jan WieckDate: 2000-02-29 00:28:11
Subject: Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group