SET SESSION CHARACTERISTICS

Started by Peter Eisentrautabout 25 years ago4 messages
#1Peter Eisentraut
peter_e@gmx.net

ISTM that

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.

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

#2Thomas Lockhart
lockhart@alumni.caltech.edu
In reply to: Peter Eisentraut (#1)
Re: SET SESSION CHARACTERISTICS

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"? 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. So I kept
the original syntax and just added the statements that SQL99 calls out
explictly. Also, our "SET" syntax has lots more keywords than specified
in SQL99...

- Thomas

#3Peter Eisentraut
peter_e@gmx.net
In reply to: Thomas Lockhart (#2)
Re: SET SESSION CHARACTERISTICS

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/

#4Thomas Lockhart
lockhart@alumni.caltech.edu
In reply to: Peter Eisentraut (#3)
Re: SET SESSION CHARACTERISTICS

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.

OK.

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.

Sure.

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.

OK, so maybe my recollection is not very good...

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.

Well, no argument really ;)

I put the SET SESSION CHARACTERISTICS in as a start at the SQL99-defined
functionality. Now would be a good time to make it right.

- Thomas