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
