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 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
