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
