Re: persistent portals/cursors (between transactions)
От | Jan Wieck |
---|---|
Тема | Re: persistent portals/cursors (between transactions) |
Дата | |
Msg-id | 200201250518.g0P5IBM01992@saturn.janwieck.net обсуждение исходный текст |
Ответ на | Re: persistent portals/cursors (between transactions) (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-general |
Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > >> I forgot to mention that I'd like to implement a cross > > >> transaction insensitive(and read-only) cursors which > > >> any proper dbms seems to have the functionality. > > > > > That is a good idea, especially read-only, that will not require any > > > locks. > > > > If it's not holding any locks, I can guarantee you it's not insensitive. > > Consider VACUUM, or even DROP TABLE. > > I assumed it would be an in-memory copy of the cursor, like a portal > that doesn't go away on transaction exit. Ever realized what a portal is? So far it's a query for which ExecutorStart() has been called, just sitting there, waiting for subsequent ExecutorRun() calls. How such a thing can live outside of any transaction context isn't totally clear to me, even if I have to admit that I see by now the desire for cross transaction cursors. It's just these lil' details like "how does the portal maintain it's snapshot POV after the transaction creating it is long gone?", that make me nervous. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com # _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
В списке pgsql-general по дате отправления: