Re: [PATCHES] Fixes gram.y - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] Fixes gram.y
Date
Msg-id 21084.1016646311@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] Fixes gram.y  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: [PATCHES] Fixes gram.y
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> Hmm.  Looks like we need a wholesale revision of command tags, indeed.

> We would need to do:

> ALTER  -> ALTER <type of object>
> DROP   -> DROP <type of object>
> CREATE -> CREATE <type of object>
> Those look reasonable, and we already do that in some cases.

These seem okay to me.

> CLOSE   -> CLOSE CURSOR
> DECLARE -> DECLARE CURSOR
> No opinion here.

No strong feeling here either.

> COMMIT   -> COMMIT WORK
> ROLLBACK -> ROLLBACK WORK
> Doesn't matter to me.

I'd vote against changing these.

> DELETE -> DELETE WHERE
> UPDATE -> UPDATE WHERE
> I'd prefer not to do those.

If we change these we will break existing client code that expects a
particular format for these tags (so it can pull out the row count).
Definitely a "no change" vote here.

> SET CONSTRAINTS -> SET CONSTRAINT [sic]
> SET VARIABLE    -> SET TIME ZONE
> SET VARIABLE    -> SET TRANSACTION
> SET VARIABLE    -> SET SESSION AUTHORIZATION
> The first one looks like a mistake.  The other ones we could work on.

I'd say leave them all as "SET VARIABLE".  There's no real information
gain here, and I'm a tad worried about overflowing limited command-tag
buffers in clients.

> It also seems to me that CREATE TABLE AS should not print "SELECT".  I
> thought Fernando Nasser had fixed that.

No, I think it's still on his to-do list (we didn't like his first
proposed patch for it).

            regards, tom lane

pgsql-hackers by date:

Previous
From: "Luis Alberto Amigo Navarro"
Date:
Subject: Re: Fw: Fw: bad performance on irix
Next
From: Bear Giles
Date:
Subject: Re: XML