From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Josh Berkus <josh(at)agliodbs(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: "stored procedures" |
Date: | 2011-04-22 13:09:49 |
Message-ID: | BANLkTimidZxu823O0iLeiaLuEXfsW8sTzA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 21, 2011 at 8:34 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Apr 21, 2011, at 3:51 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>> If you do it that (base it on AT) way, then you can't:
>> 1) call any utility command (vacuum, etc)
>> 2) run for an arbitrary amount of time
>> 3) discard any locks (except advisory)
>> 4) deal with serialization isolation/mvcc snapshot issues that plague functions.
>
> It is not obvious to me that you cannot do these things.
yeah...I think I misunderstood what you were saying ("When you enter a
stored procedure at the outermost level, you begin a transaction...").
Those restrictions only apply when there is a open transaction
controlling the context of what is running. If you are handing the
command textually off to another backend which then runs it, then you
are mostly good...although #2 still might be a problem, and #3 if you
happen to grab any.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Yves Weißig | 2011-04-22 13:29:32 | What Index Access Method Functions are really needed? |
Previous Message | Greg Smith | 2011-04-22 12:35:09 | Re: fsync reliability |