Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Feb 20, 2010 at 4:41 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>> IMNSHO, an 'in core' scheduler would be useful. however, I think
>> before you tackle a scheduler, we need proper stored procedures. Our
>> existing functions don't cut it because you can manage the transaction
>> state yourself.
> Did you mean that you "can't" manage the transaction state yourself?
> Has anyone given any thought to what would be required to relax this
> restriction? Is this totally impossible given our architecture, or
> just a lack of round tuits?
There is lots and lots of discussion of that in the archives. It's
fundamentally impossible for PL functions done in the current style to
start or commit transactions, unless you resort to dblink-style kluges.
What's been discussed is some sort of structure that would allow a chunk
of PL code to execute "outside" a transaction and thus issue its own
begin and commit commands. This idea is what Merlin is calling a stored
procedure, though personally I dislike that terminology. Anyway,
nothing's got past the arm-waving stage as yet.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Ed L.||Date: 2010-03-02 00:12:36|
|Subject: Re: Hung postmaster (8.3.9)|
|Previous:||From: Andrew Dunstan||Date: 2010-03-02 00:08:05|
|Subject: Re: [Feature request] variable declaration of anonymous
composite data type in PL/pgSQL|