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

Re: functions returning sets

From: Alex Pilosov <alex(at)pilosoft(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: functions returning sets
Date: 2001-06-29 21:26:51
Message-ID: Pine.BSO.4.10.10106291716490.13871-100000@spider.pilosoft.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, 29 Jun 2001, Tom Lane wrote:

> 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.

Well, a lot of things (planner for ex) need to know relid of the relation
being returned. If a function returns setof int4, for example, what relid
should be filled in? 

Variables (for example) have to be bound to relid and attno. If a function
returns setof int4, what should be variables' varno be?

Assigning 'fake' relids valid for length of query (from a low range) may
be a solution if you agree?

> > I have a special RELKIND_FUNC for parser,
> 
> This seems totally wrong.
Probably :)

> > 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.

Okay. So the logic should support 'select * from foo' where foo is portal,
right? Then I _do_ have to deal with a problem of unknown relid to bind
variables to...

-alex


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-06-29 21:32:22
Subject: Re: functions returning sets
Previous:From: Peter EisentrautDate: 2001-06-29 21:20:36
Subject: Re: Configuration of statistical views

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