Re: [Fwd: [PATCHES] contrib/showguc (was Re: revised sample
От | Peter Eisentraut |
---|---|
Тема | Re: [Fwd: [PATCHES] contrib/showguc (was Re: revised sample |
Дата | |
Msg-id | Pine.LNX.4.44.0206192201200.929-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: [Fwd: [PATCHES] contrib/showguc (was Re: revised sample (Joe Conway <mail@joeconway.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: