SAVEPOINT syntax again

Making the assumption that we want standards-conforming syntax here, I
went ahead and did the necessary changes:

Oliver Jowett wrote:

Comments:

1) We have a different syntax to the SQL200n draft (and Oracle by the
looks of it) for ROLLBACK. The draft says:

<rollback statement> ::= ROLLBACK [ WORK ] [ AND [ NO ] CHAIN ] [
<savepoint clause> ]
<savepoint clause> ::= TO SAVEPOINT <savepoint specifier>

Oracle has ROLLBACK TO [ SAVEPOINT ] <savepoint specifier>
DB2 has ROLLBACK TO SAVEPOINT <savepoint specifier>

2) We have a different syntax for RELEASE too. The SQL200n draft says:

<release savepoint statement> ::= RELEASE SAVEPOINT <savepoint specifier>

Oracle does not have RELEASE SAVEPOINT.
DB2 has RELEASE [ TO ] SAVEPOINT <savepoint specifier>

The attached patch implements an approximate union of the above syntaxes:

ROLLBACK [ WORK | TRANSACTION ] TO [ SAVEPOINT ] <savepoint specifier>
RELEASE [ TO ] SAVEPOINT <savepoint specifier>

Note that this means that "RELEASE foo" is no longer valid. It seems
solely a postgresql-ism -- anyone particularly attached to that syntax?

Also in the patch are documentation and regression test updates to
reflect the new syntax. I have changed the examples in the docs and the
regression tests to prefer the standard-conforming variants. Error
messages now refer to ROLLBACK TO SAVEPOINT and RELEASE SAVEPOINT rather
than ROLLBACK TO and RELEASE.

-O

Oliver Jowett <oliver@opencloud.com> writes:

Oracle has ROLLBACK TO [ SAVEPOINT ] <savepoint specifier>
DB2 has ROLLBACK TO SAVEPOINT <savepoint specifier>

I would go with Oracle's lead here, first because they are the de facto
standard, and second because I don't want to have to type out SAVEPOINT
every time I use one of these commands.

<release savepoint statement> ::= RELEASE SAVEPOINT <savepoint specifier>

Oracle does not have RELEASE SAVEPOINT.
DB2 has RELEASE [ TO ] SAVEPOINT <savepoint specifier>

I'd vote for RELEASE [ SAVEPOINT ] <name> (for brevity, and for
consistency with ROLLBACK). I feel no urge to copy DB2.

regards, tom lane

Tom Lane wrote:

Oliver Jowett <oliver@opencloud.com> writes:

Oracle has ROLLBACK TO [ SAVEPOINT ] <savepoint specifier>
DB2 has ROLLBACK TO SAVEPOINT <savepoint specifier>

I would go with Oracle's lead here, first because they are the de facto
standard, and second because I don't want to have to type out SAVEPOINT
every time I use one of these commands.

<release savepoint statement> ::= RELEASE SAVEPOINT <savepoint specifier>

Oracle does not have RELEASE SAVEPOINT.
DB2 has RELEASE [ TO ] SAVEPOINT <savepoint specifier>

I'd vote for RELEASE [ SAVEPOINT ] <name> (for brevity, and for
consistency with ROLLBACK). I feel no urge to copy DB2.

Are we ever going to use "RELEASE" for prepared statements? If so
making SAVEPOINT optional might be a bad idea.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Are we ever going to use "RELEASE" for prepared statements? If so
making SAVEPOINT optional might be a bad idea.

No, why would we? Their verb is DEALLOCATE.

regards, tom lane

Tom Lane wrote:

Oliver Jowett <oliver@opencloud.com> writes:

<release savepoint statement> ::= RELEASE SAVEPOINT <savepoint specifier>

Oracle does not have RELEASE SAVEPOINT.
DB2 has RELEASE [ TO ] SAVEPOINT <savepoint specifier>

I'd vote for RELEASE [ SAVEPOINT ] <name> (for brevity, and for
consistency with ROLLBACK). I feel no urge to copy DB2.

Here's an updated patch that supports the syntax you suggest. I kept the
error messages, doc examples and regression tests using RELEASE
SAVEPOINT in full to follow the standard.

-O

Oliver Jowett <oliver@opencloud.com> writes:

Here's an updated patch that supports the syntax you suggest. I kept the
error messages, doc examples and regression tests using RELEASE
SAVEPOINT in full to follow the standard.

As long as we're tweaking syntax to agree with the spec ...

I notice that both SQL99 and SQL2003 require commas between the options
for START TRANSACTION and SET TRANSACTION, whereas our current grammar
has no commas. I propose that we fix the grammar to allow optional
commas there, to support the standard syntax without breaking existing
apps.

Unless someone objects, I'll add this to Oliver's patch and commit.

regards, tom lane

Oliver Jowett <oliver@opencloud.com> writes:

Here's an updated patch that supports the syntax you suggest. I kept the
error messages, doc examples and regression tests using RELEASE
SAVEPOINT in full to follow the standard.

Applied. I had to tweak the grammar changes a bit --- the patch as
given created shift/reduce warnings, which we have a project policy
against allowing.

regards, tom lane