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

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