Re: Static snapshot data

Поиск
Список
Период
Сортировка
От Alvaro Herrera Munoz
Тема Re: Static snapshot data
Дата
Msg-id 20030523141723.GB28857@dcc.uchile.cl
обсуждение исходный текст
Ответ на Re: Static snapshot data  (Manfred Koizar <mkoi-pg@aon.at>)
Ответы Re: Static snapshot data  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Static snapshot data  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera Munoz
Дата:
Сообщение: Re: Un-clustering an index
Следующее
От: Michael Brusser
Дата:
Сообщение: vacuum analyze corrupts database