On Mon, Dec 31, 2012 at 12:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
On the whole I think this is a must fix bug, so we don't have a lot of
choice, unless someone has a proposal for a different and more compact
way of solving the problem.
The only more compact way of handling things that I can
Greg Stark st...@mit.edu writes:
I do wonder whether the SQL standard will do something obtuse enough
that that's the only option for a large swathe of queries. Or is that
the case already? The query syntax you're using here, is it standard
SQL? Is it widely supported?
Yeah, it's standard ---
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 21, 2012 at 9:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm suggesting that we could fix this by emitting something that forces
the right alias to be assigned to t2.q:
SELECT t1.x, t1.y, t2.z
FROM t1
JOIN t2 AS t2(x,z)
USING (x);
On Fri, Dec 21, 2012 at 9:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I'm having a hard time following this. Can you provide a concrete example?
regression=# create table t1 (x int, y int);
CREATE TABLE
regression=# create table t2 (x int, z int);
In commit 11e131854f8231a21613f834c40fe9d046926387 we rearranged
ruleutils.c's handling of relation aliases to ensure that views can
always be dumped and reloaded even in the face of confusing table
renamings. I was reminded by
http://archives.postgresql.org/pgsql-general/2012-12/msg00654.php
On Fri, Dec 21, 2012 at 6:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In commit 11e131854f8231a21613f834c40fe9d046926387 we rearranged
ruleutils.c's handling of relation aliases to ensure that views can
always be dumped and reloaded even in the face of confusing table
renamings. I was reminded
Robert Haas robertmh...@gmail.com writes:
I'm having a hard time following this. Can you provide a concrete example?
regression=# create table t1 (x int, y int);
CREATE TABLE
regression=# create table t2 (x int, z int);
CREATE TABLE
regression=# create view v1 as select * from t1 join t2 using
