On Wed, Mar 21, 2012 at 10:58 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:

> Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> writes:
> > Consider following sequence of commands
> > create type complex as (r float8, i float8);
> > create type quad as (c1 complex, c2 complex);
> > create temp table quadtable(f1 int, q quad);
> > insert into quadtable (f1, q.c1.r, q.c2.i) values(44,55,66);
> > While parsing the INSERT query, we parse the query with three columns and
> > three values in the target list, but during rewriting we combine q.c1.r
> and
> > q.c2.i into a single column in the form of FieldStore structure. In
> > Postgres-XC, we deparse these parse trees, to be sent to other PostgreSQL
> > servers.
> Well, basically you have a broken design there.  We are not going to
> adopt a restriction that post-rewrite trees are necessarily exactly
> representable as SQL, so there are going to be corner cases where this
> approach fails.

That's an optimization, and in the cases it fails, we fall back to basics.
If there are known differences, please let us know.

> > The assertion is added by commit 858d1699. The notes for the commit have
> > following paragraph related to FieldStore deparsing.
> >     I chose to represent an assignment ArrayRef as "array[subscripts] :=
> > source",
> >     which is fairly reasonable and doesn't omit any information.
>  However,
> >     FieldStore is problematic because the planner will fold multiple
> > assignments
> >     to fields of the same composite column into one FieldStore, resulting
> > in a
> >     structure that is hard to understand at all, let alone display
> > comprehensibly.
> >     So in that case I punted and just made it print the source
> > expression(s).
> > So, there doesn't seem to be any serious reason behind the restriction.
> If you have a proposal for some reasonable way to print the actual
> meaning of the expression (and a patch to do it), we can certainly
> consider changing that code.  I don't think it's possible to display it
> as standard SQL, though.  The ArrayRef case is already not standard SQL.
Let me try to come up with a patch.

                       regards, tom lane

Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company

Reply via email to