Re: Accessing original TupleDesc from SRF

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: John Gray <jgray(at)azuli(dot)co(dot)uk>, Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Accessing original TupleDesc from SRF
Date: 2002-08-30 15:33:40
Message-ID: 3D6F9054.5020900@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> I've been thinking more about this, and wondering if we should not
> only make the tupdesc available but rely more heavily on it than we
> do. Most of the C-coded functions do fairly substantial pushups to
> construct tupdescs that are just going to duplicate what
> nodeFunctionscan already has in its back pocket. They could save some
> time by just picking that up and using it.
>
> On the other hand, your experience yesterday with debugging a mismatched
> function declaration suggests that it's still a good idea to make the
> functions build the tupdesc they think they are returning.

In a function which *can* know what the tupledec should look like based
on independent information (contrib/tablefunc.c:crosstab), or based on a
priori knowledge (guc.c:show_all_settings), then the passed in tupdesc
could be used by the function to validate that it has been acceptably
declared (for named types) or called (for anonymous types).

But it is also interesting to let the function try to adapt to the way
in which it has been called, and punt if it can't deal with it. And in
some cases, like John's example, there *is* no other way.

Joe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Iavor Raytchev 2002-08-30 15:44:12 pgaccess - where to store the own data
Previous Message Tom Lane 2002-08-30 15:26:06 Re: Accessing original TupleDesc from SRF