From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: revised sample SRF C function; proposed SRF API |
Date: | 2002-06-09 02:32:04 |
Message-ID: | 3D02BE24.5080008@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
> Well, we're not doing that; and I see no good reason to make the thing
> be a builtin function at all. Since it's just an example, it can very
> well be a contrib item with a creation script. Probably *should* be,
> in fact, because dynamically created functions are what other people are
> going to be building; an example of how to do it as a builtin function
> isn't as helpful.
True enough, although I could always create another example for contrib.
Returning GUC variable "SHOW ALL" results as a query result has been
discussed before, and I thought there was agreement that it was a
desirable backend feature.
Is the approach in my patch still too ugly to allow a builtin SRF (set
the function return type to 0 in pg_proc.h, create a view and fix the
pg_proc entry during initdb)? If so, I'll rework the patch into two
patches: one for the composite/set returning function api, and one for
show_all_vars() as a contrib/SRF example. If not, I'll just come up with
another function for contrib to serve as a reference implementation for
others.
Thanks,
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Elphick | 2002-06-09 02:53:24 | [Fwd: Re: [Fwd: Bug#149056: postgresql: should not try in a busy loop when allocating resources]] |
Previous Message | Tom Lane | 2002-06-09 02:21:09 | Re: [Fwd: Bug#149056: postgresql: should not try in a busy |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-06-09 15:59:55 | Re: revised sample SRF C function; proposed SRF API |
Previous Message | Tom Lane | 2002-06-09 01:00:39 | Re: revised sample SRF C function; proposed SRF API |