Re: Composite Types

JanWieck@t-online.de (Jan Wieck) writes:
>     Exactly correct. The original POSTQUEL parser had support  to
>     extract a single attribute from a function returning a tuple.
>     Someone also attempted to add a  targetlist  to  Func  nodes.

That wasn't there originally, huh?  Interesting, because I have been
thinking about ripping it out again.  It's essentially useless as it
stands; the only thing any code does with it is to decide whether
an SQL function should return the whole tuple that its final SELECT
produces, or extract a single Datum from the tuple.  That could be
done with a simple int field ("extract attr N from tuple").

Since the targetlists attached to Func nodes clutter the parsetree
quite a lot and bulk up stored rule strings, getting rid of them
seems like a good idea.

>     For the rewriter, I know that VIEWs will be a nobrainer.  But
>     all  other  rewriting  rules on INSERT/UPDATE/DELETE, turning
>     views into tables, don't appear to be  that  easy  any  more.
>     Actually we have a central rangetable, and the target is just
>     "0" (meaning client) or the RTE index of the query. With  the
>     new  querytree concept, we'd loose the central rangetable, so
>     application of modifying rules might not be that  simple  any
>     more.

There'd still be a rangetable for the target of INSERT/UPDATE/DELETE,
I imagine.  One thing we should think about while we're in there is
supporting INSERT/UPDATE/DELETE directed to multiple tables (for
inheritance).

            regards, tom lane