BUG #7658: the result of pg_get_viewdef can NOT execute directly
The following bug has been logged on the website:
Bug reference: 7658
Logged by: ZouLixian
Email address: zoulx1982@163.com
PostgreSQL version: 9.2.0
Operating system: Linux
Description:
postgres=#
postgres=# select version();
version
------------------------------------------------------------------------------------------------------------
-------
PostgreSQL 9.2.0 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.1.2
20080704 (Asianux 3.0 4.1.2-44),
64-bit
(1 row)
postgres=#
postgres=# create table t1(a int, b int);
CREATE TABLE
postgres=# create table t2(c int, d int);
CREATE TABLE
postgres=# create view v as select * from t1 t where a in (select a from t2
t);
CREATE VIEW
postgres=# select pg_get_viewdef('v');
pg_get_viewdef
------------------------------------------------------------------
SELECT t.a, t.b FROM t1 t WHERE (t.a IN (SELECT t.a FROM t2 t));
(1 row)
postgres=# SELECT t.a, t.b FROM t1 t WHERE (t.a IN (SELECT t.a FROM t2 t));
ERROR: column t.a does not exist
LINE 1: SELECT t.a, t.b FROM t1 t WHERE (t.a IN (SELECT t.a FROM t2 ...
^
postgres=#
postgres=#
zoulx1982@163.com writes:
postgres=# create table t1(a int, b int);
CREATE TABLE
postgres=# create table t2(c int, d int);
CREATE TABLE
postgres=# create view v as select * from t1 t where a in (select a from t2
t);
CREATE VIEW
postgres=# select pg_get_viewdef('v');
pg_get_viewdef
------------------------------------------------------------------
SELECT t.a, t.b FROM t1 t WHERE (t.a IN (SELECT t.a FROM t2 t));
(1 row)
This is fixed in HEAD as a consequence of commit
http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=11e131854f8231a21613f834c40fe9d046926387
--- I getSELECT t.a, t.b FROM t1 t WHERE (t.a IN (SELECT t.a FROM t2 t_1));
which is a valid representation of the view. At the time we felt it was
not worth the risk of back-patching. I'm still inclined to think that,
since this example doesn't seem to correspond to any real-world use case
(the original query is surely a mistake no?).
regards, tom lane