From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Reconstructing Insert queries with indirection |
Date: | 2012-03-21 17:28:51 |
Message-ID: | 6253.1332350931@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)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.
> 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Tautschnig | 2012-03-21 18:09:35 | Re: Weak-memory specific problem in ResetLatch/WaitLatch (follow-up analysis) |
Previous Message | Robert Haas | 2012-03-21 17:02:18 | Re: [v9.2] Add GUC sepgsql.client_label |