| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jim Nasby <jim(at)nasby(dot)net>, Joachim Wieland <joe(at)mcknight(dot)de>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: synchronized snapshots |
| Date: | 2011-08-17 02:07:56 |
| Message-ID: | CA+TgmoaszGmuTEALXCwGWjZ7Wz20tiD0Wk2AzZXDs4XSGCypHQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Aug 16, 2011 at 9:54 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>> If we did add another toplevel command, what would we call it?
>
> "SET TRANSACTION SNAPSHOT" perhaps?
Hmm, that's not bad, but I think we'd have to partially reserve
TRANSACTION to make it work, which doesn't seem worth the pain it
would cause.
We could do something like TRANSACTION SNAPSHOT IS 'xyz', but that's a
bit awkard.
I still like BEGIN SNAPSHOT 'xyz' -- or even adding a generic options
list like we use for some other commands, i.e. BEGIN (snapshot 'xyz'),
which would leave the door open to arbitrary amounts of future
nonstandard fiddling without the need for any more keywords. I
understand the point about the results of a BEGIN failure leaving you
outside a transaction, but that really only matters if you're doing
"psql < dumb_script.sql", which is impractical for this feature
anyway.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2011-08-17 02:17:21 | Re: pgsql: In pg_upgrade, avoid dumping orphaned temporary tables. This ma |
| Previous Message | Joe Abbate | 2011-08-17 02:00:59 | Re: Finding tables dropped by DROP TABLE CASCADE |