<moving back to HACKERS for the discussion> Peter Eisentraut wrote: > OK, I've been looking at this package for some time through various > iterations and I have my doubts about it. > > What's going to happen to this when SHOW ALL is changed to return a query > result? If you want to provide an example of a set-returning function, > use something of lasting value, maybe generate some mathematic sequence.
Well, I wanted to implement this as a functional equivalent of SHOW ALL, in the backend, but there was no way to bootstrap a builtin SRF that wasn't also too ugly to be acceptable (at least that I could come up with -- any suggestions?). And while SHOW ALL *could* be implemented in a similar fashion to EXPLAIN, with that approach you could not use a WHERE clause, or join the results with any other data. IMHO that significantly reduces the utility of returning SHOW ALL results as a query in the first place. I'd be happy to produce a different function as a reference implementation, but it seemed that there was sufficient demand in the past that this was a useful example. If the consensus is that contrib/showguc (renamed, see below) is a bad idea, then I'll come up with something else. > > Also, the first place this sort of material should go is the > documentation, not hidden somewhere in contrib. No doubt, and there *will* be documentation. I was waiting for the API and example to stabilize a bit first. There is no sense in documenting a moving target. > > In any case, please don't expose the name "GUC" to user space. OK. If I replace user space references to GUC with something more palatable, are the guc.c and guc.h changes at least acceptable? With them, user functions can at least read configuration variables. GUC variables are inaccessible otherwise. Please let me know the desired direction for this, and I'll adjust accordingly. Thanks, Joe ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org