Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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.


In response to


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group