Thread: Re: [Fwd: [PATCHES] contrib/showguc (was Re: revised sample

<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

Joe Conway writes:

> 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?).

Well, if you want to provide a really simple example (which might not be a
bad idea), just return N random numbers, where N is passed as an argument.
If you want to add some substance, generate those numbers yourself using
some algorithm to achieve a certain kind of distribution.  (This might
require you to keep some state between calls, which would be interesting
to see.)

As far as returning composite types, that's really a separate thing, so
there ought to be a separate example.

> 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.

SHOW ALL is a red herring.  What we need is simple SHOW to return a query
result.  Or we need a simple function that takes one argument of type text
(or name) and returns one datum of type text with the value of the
parameter.  If, as you say, you'd like to join the results with other
computations, the latter would be for you.


A random observation:  Your SRF API seems to require that you determine
the maximum number of calls ahead of time.  Is this necessary?  It might
be interesting, for instance, to create mathematical sequences and have it
terminate at some condition.  Instead of the max_calls and call counter
you could provide some space for free use.

-- 
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut wrote:
> Well, if you want to provide a really simple example (which might not be a
> bad idea), just return N random numbers, where N is passed as an argument.
> If you want to add some substance, generate those numbers yourself using
> some algorithm to achieve a certain kind of distribution.  (This might
> require you to keep some state between calls, which would be interesting
> to see.)
> 
> As far as returning composite types, that's really a separate thing, so
> there ought to be a separate example.


OK. I'll create a simpler example of both returning composite and 
returning a set.


> SHOW ALL is a red herring.  What we need is simple SHOW to return a query
> result.  Or we need a simple function that takes one argument of type text
> (or name) and returns one datum of type text with the value of the
> parameter.  If, as you say, you'd like to join the results with other
> computations, the latter would be for you.

Fair enough. There was already a function in the submitted contrib which 
did just that. I'll rework it into a backend function and resubmit.


> A random observation:  Your SRF API seems to require that you determine
> the maximum number of calls ahead of time.  Is this necessary?  It might
> be interesting, for instance, to create mathematical sequences and have it
> terminate at some condition.

The max calls is a purely optional part of the API. If a different way 
of determining when you're "done" exists for a particular application, 
that should be used instead. I will make sure this fact is prominent in 
the documentation.
> Instead of the max_calls and call counter you could provide some space> for free use.

Well, that was the idea with:/* pointer to misc context info */void           *fctx;
You can use this to keep track of any context info you want. I suppose 
call_cntr and max_calls could be part of the user provided context, but 
since they will be used frequently (at least in my experience so far 
they have been needed each time), I thought making them part of the 
structure for the sake of convenience was worth it.

Thank you for the feedback!

Joe