> Tom Lane wrote:
> > Well, we're not doing that; and I see no good reason to make the thing
> > be a builtin function at all. Since it's just an example, it can very
> > well be a contrib item with a creation script. Probably *should* be,
> > in fact, because dynamically created functions are w
Joe Conway <[EMAIL PROTECTED]> writes:
> Returning GUC variable "SHOW ALL" results as a query result has been
> discussed before, and I thought there was agreement that it was a
> desirable backend feature.
So it is, but I had expected it to be implemented by changing the
behavior of SHOW, same
Tom Lane wrote:
> Well, we're not doing that; and I see no good reason to make the thing
> be a builtin function at all. Since it's just an example, it can very
> well be a contrib item with a creation script. Probably *should* be,
> in fact, because dynamically created functions are what other
Joe Conway <[EMAIL PROTECTED]> writes:
> The question is how to best bootstrap this new function. In order to
> create the pg_proc entry I need the return type oid. If I understand
> correctly, in order to get a composite return type, with a known oid, I
> would need to create a bootstrapped re
Tom Lane wrote:
> Definitely better. I'd suggest also thinking about whether the
> same/similar macros can support functions that return a set of a
> scalar (non-tuple) datatype. In my mind, the cleanest design would
> be some base macros that support functions-returning-set (of anything),
> and
Tom Lane wrote:
> Definitely better. I'd suggest also thinking about whether the
> same/similar macros can support functions that return a set of a
> scalar (non-tuple) datatype. In my mind, the cleanest design would
> be some base macros that support functions-returning-set (of anything),
> and
Joe Conway <[EMAIL PROTECTED]> writes:
> What if we also had something like:
> FUNC_BUILD_TUPLE(values, funcctx);
> which returns a tuple for the less experienced folks
Sure, as long as it's not getting in the way when you don't want it.
For that matter the FUNC stuff shouldn't get in the way
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
>
>> If not, prepare an array of C strings representing the attribute
>> values of your return tuple, and call: FUNC_BUILD_SLOT(values,
>> funcctx);
>
> I think that's a poor choice of abstraction, as it forces the user
> into the le
Peter Eisentraut wrote:
> We need a function like this in the main line. The "show all" variety
> isn't top priority, but we need something that gets you the "show" result
> as a query output. The original idea was to make SHOW return a query
> result directly, but a function is fine with me too
Joe Conway writes:
> Here is a revised patch for a sample C function returning setof
> composite. (Same comments as last time -- It is a clone of SHOW ALL as
> an SRF. For the moment, the function is implemented as contrib/showguc,
> although a few minor changes to guc.c and guc.h were required t
Joe Conway <[EMAIL PROTECTED]> writes:
> If not, prepare an array of C strings representing the
> attribute values of your return tuple, and call:
> FUNC_BUILD_SLOT(values, funcctx);
I think that's a poor choice of abstraction, as it forces the user into
the least-efficient-possible way of b
Joe Conway wrote:
> Here is a revised patch for a sample C function returning setof
> composite. (Same comments as last time -- It is a clone of SHOW ALL as
> an SRF. For the moment, the function is implemented as contrib/showguc,
> although a few minor changes to guc.c and guc.h were required
12 matches
Mail list logo
