From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
Cc: | mjp(at)ornl(dot)gov, pgsql-general(at)postgresql(dot)org, parangm(at)ornl(dot)gov |
Subject: | Re: Composite Types |
Date: | 2000-06-08 14:53:49 |
Message-ID: | 16062.960476029@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
JanWieck(at)t-online(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-06-08 15:01:20 | Re: two postgres servers on one machine? |
Previous Message | Tom Lane | 2000-06-08 14:46:04 | Re: Column types via ODBC interface |