<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
