Re: SET SESSION CHARACTERISTICS - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: SET SESSION CHARACTERISTICS
Date
Msg-id Pine.LNX.4.21.0011211702420.781-100000@peter.localdomain
Whole thread Raw
In response to Re: SET SESSION CHARACTERISTICS  (Thomas Lockhart <lockhart@alumni.caltech.edu>)
List pgsql-hackers
Thomas Lockhart writes:

> >    SET SESSION CHARACTERISTICS AS parameter value
> > is really a more SQL'ish form of the current
> >    SET parameter =/TO value
> > Perhaps they should be made equivalent, in order to avoid too many subtly
> > different subversions of the 'SET' command.
> 
> Hmm. What do you mean by "equivalent"?

That they have the same effect when invoked.

> I assumed that the incredibly
> verbose SQL99 form is not particularly gratifying to type, and that we
> would be interested in a shorter version of the same thing.

Definitely.  But it would also be nice if we didn't have too many SET
commands that have intersecting functionality but where it's not quite
clear which controls what.  Given that our custom short SET variant does
effectively control "session characteristics" it only seemed logical to me
that we could map it to the more SQL'ish variant.

> So I kept the original syntax and just added the statements that SQL99
> calls out explictly.

Then I don't know where you got the TRANSACTION COMMIT and TIME ZONE
clauses from.  SQL 99 doesn't have the former anywhere, and the latter
only as 'SET TIME ZONE' which we have already.

> Also, our "SET" syntax has lots more keywords than specified in
> SQL99...

Hmm, is it your argument that we should keep our custom parameters in our
custom command in order to avoid conflicts with future standards?  Maybe
so, but then we already lose.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: (download ANSI SQL benchmark?) Re: Postgres article
Next
From: Thomas Lockhart
Date:
Subject: Re: SET SESSION CHARACTERISTICS