Re: [HACKERS] SQL statements: begin and end
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] SQL statements: begin and end |
Дата | |
Msg-id | 6087.943369194@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | SQL statements: begin and end (Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>) |
Ответы |
Re: [HACKERS] SQL statements: begin and end
Re: [HACKERS] SQL statements: begin and end |
Список | pgsql-hackers |
Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at> writes: > I see everybody using the following PostgreSQL statements: > "begin" instead of "begin work" > "end" instead of "commit work" > This is really bad, because it is not standard, I went looking in the SQL spec to confirm this, and was rather startled to discover that BEGIN is not SQL at all! The SQL spec seems to envision the always-in-a-transaction-block model of operation. They have <commit statement> ::= COMMIT [ WORK ] which is defined to commit the current transaction; but a new xact is implicitly started by the next SQL operation (cf. sec. 4.28 in SQL92). If we wanted to be completely standards-conformant, I think we'd have to abandon the begin/end model entirely. I wouldn't support that --- auto commit of standalone statements is too convenient. Bottom line: pointing at the spec is a very weak argument for telling people how to spell their begin/end statements. > I vote for issuing a NOTICE for these in V7 and remove them in V8, > at least the single "end" My feeling is that application authors have already decided whether they prefer "BEGIN" or "BEGIN TRANSACTION" or "BEGIN WORK", and trying to enforce a single standard now is just going to irritate people and break existing applications. I vote for leaving well enough alone. > Bruce, please don't use "begin" and "end" in your book. Sure, it makes sense for the book to consistently use "BEGIN WORK" and "COMMIT WORK", which are probably the least likely to confuse novices. But I think actually removing the other variants would be just an exercise in causing trouble. regards, tom lane
В списке pgsql-hackers по дате отправления: