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
