Re: Static snapshot data - Mailing list pgsql-hackers

From Alvaro Herrera Munoz
Subject Re: Static snapshot data
Date
Msg-id 20030523141723.GB28857@dcc.uchile.cl
Whole thread Raw
In response to Re: Static snapshot data  (Manfred Koizar <mkoi-pg@aon.at>)
Responses Re: Static snapshot data  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Static snapshot data  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, May 23, 2003 at 12:17:21PM +0200, Manfred Koizar wrote:
> On Sat, 17 May 2003 19:14:25 -0400, Alvaro Herrera
> <alvherre@dcc.uchile.cl> wrote:

> >I see.  Then I don't fully agree with your rules.  Let's say I find that
> >the rules are very good guidelines, but they fail WRT the isolation
> >level, which is a special exception.
> 
> If there is not a compelling reason for making things more
> complicated, I vote for implementing the most simple usable solution,
> i.e. the whole transaction tree has to run with the same isolation
> level.

Ok, I'll do this and if it's needed the other thing can be done later.

> BTW, do we have to invent a new syntax for starting and ending
> subtransactions?  COMMIT/ROLLBACK should be no problem.  But does
> BEGIN [subtransaction] conflict with BEGIN ... END in pl/pgslq?

I don't think we have to create a new syntax for starting a
subtransaction in the main parser.  But the PL/pgSQL parser will have to
be changed somehow.  I don't know a bit about parsers but maybe it's
possible to require a "BEGIN TRANSACTION" command to start a new
transaction so it doesn't conflicts with plpgsql's BEGIN.  It'll be
confusing for sure if we don't do it this way, I think.

-- 
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
Officer Krupke, what are we to do?
Gee, officer Krupke, Krup you! (West Side Story, "Gee, Officer Krupke")


pgsql-hackers by date:

Previous
From: Alvaro Herrera Munoz
Date:
Subject: Re: Un-clustering an index
Next
From: Michael Brusser
Date:
Subject: vacuum analyze corrupts database