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

Re: functions returning sets

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alex Pilosov <alex(at)pilosoft(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: functions returning sets
Date: 2001-06-29 20:25:56
Message-ID: 20749.993846356@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Alex Pilosov <alex(at)pilosoft(dot)com> writes:
> Well, I'm on my way to implement what was discussed on list before.
> I am doing it the way Karel and Jan suggested: creating a
> pg_class/pg_attribute tuple[s] for a function that returns a setof. 

What?  You shouldn't need pg_class entries for functions unless they
return *tuples*.  setof has nothing to do with that.  Moreover, the
pg_class entry should be thought of as a record type independent of
the existence of any particular function returning it.

> I have a special RELKIND_FUNC for parser,

This seems totally wrong.

> Options are:
> 1) Create a special scan node type, T_FuncSeqScan and deal with it there.
> 2) Keep the T_SeqScan, explain to nodeSeqScan special logic when dealing
> with RELKIND_FUNC relations. 
> (I prefer this one, but I would like a validation of it)
> 3) explain to heap_getnext special logic. 

I prefer #1.  #2 or #3 will imply slowing down normal execution paths
with extra clutter to deal with functions.

BTW, based on Jan's sketch, I'd say it should be more like
T_CursorSeqScan where the object being scanned is a cursor/portal.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Jan WieckDate: 2001-06-29 21:09:15
Subject: Re: functions returning sets
Previous:From: Bruce MomjianDate: 2001-06-29 19:54:07
Subject: Re: [GENERAL] rules on INSERT can't UPDATE new instance?

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