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

Re: Accessing original TupleDesc from SRF

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
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:49:57
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Joe Conway <mail(at)joeconway(dot)com> writes:
>> 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).

Yeah, I had also considered the idea of pushing the responsibility of
verifying the tupdesc matching out to the function (ie, nodeFunctionscan
wouldn't call tupdesc_mismatch anymore, but the function could).

I think this is a bad idea on balance though; it would save few cycles
and probably create lots more debugging headaches like the one you had.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Dave PageDate: 2002-08-30 15:50:52
Subject: Re: [HACKERS] pgaccess - where to store the own data
Previous:From: Alvaro HerreraDate: 2002-08-30 15:48:22
Subject: Re: contrib features during beta period

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