From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: revised sample SRF C function; proposed SRF API |
Date: | 2002-06-07 05:18:14 |
Message-ID: | 3D004216.2080705@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
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 if you want to return a set of scalar then you just use these
> directly (handing a Datum to FUNC_RETURN_NEXT). If you want to return
> a set of tuples then there are a couple extra steps that you need to
> do to build a tupdesc, build a tuple, and convert the tuple to Datum
> (which at the moment you do by putting it into a slot, but I think we
> ought to change that soon). If it were really clean then the macros
> supporting these extra steps would also work without the SRF macros,
> so that you could use 'em in a function returning a single tuple.
>
Sorry for the long delay. I just got back to this today, and I've run
into an interesting question.
I have a proposal and patch almost ready which I think pretty much meets
the above design requirements. I also wanted to incorporate a built-in
function for returning guc variables (varname text, varval text),
consistent with previous posts. This is both useful and a good test of
the Composite & SRF function API (the API includes functions/macros to
facilitate returning composite types, and an independent set of
functions/macros for returning sets, whether composite or scalar).
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 relation and the corresponding
bootstrapped pg_type entry.
Is there any alternative? It seems ugly to bootstrap so many objects for
every (future) builtin function which returns a composite type.
Thanks,
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-06-07 05:24:33 | Re: SASL, compression? |
Previous Message | Bruce Momjian | 2002-06-07 05:11:22 | Re: Redhat 7.3 time manipulation bug |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-06-07 21:41:09 | Re: [PATCHES] A bug in gist code with fetch/move |
Previous Message | snyder | 2002-06-07 05:18:06 | guc.c and postgresql.conf.sample constistency checker |