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