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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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