Skip site navigation (1) Skip section navigation (2)

Re: WIP patch: convert SQL-language functions to return tuplestores

From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Dimitri Fontaine" <dfontaine(at)hi-media(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Martijn van Oosterhout" <kleptog(at)svana(dot)org>
Subject: Re: WIP patch: convert SQL-language functions to return tuplestores
Date: 2008-10-29 13:07:34
Message-ID: 603c8f070810290607t7f00bd1bud8865e7a376fe7ca@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
> So my idea would be to have the SQL function behavior choose to return values
> either via tuplestore or via value-per-call, depending on the user
> setting "generator" or "lazy".
> Done this way, the user could also choose for the function to be lazy or to
> use a tuplestore whatever the language in which it's written.

The problem is not the general PostgreSQL executor, but whatever body
of code executes PL/pgsql functions (and other PL languages).  It does
not, as I understand it, support freezing execution of the function
midway through and picking up again later.  I haven't looked at the
code, but based on previous experience, that could turn out to be a
pretty major refactoring. I suspect it would be worthwhile and quite
welcome to many users - but I doubt very much that it would be easy.

...Robert

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2008-10-29 13:17:18
Subject: Re: Updating FSM on recovery
Previous:From: Greg SmithDate: 2008-10-29 13:05:21
Subject: Re: Decreasing WAL size effects

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group