Hi,
Kathy (CCed) just found a bug in BDR that turned out to actually be a
bug in postgres.
CREATE VIEW v_03 AS
SELECT * FROM (SELECT '2' ORDER BY 1) s;
postgres[l]=# \d+ v_03
View "public.v_03"
┌──────────┬──────┬───────────┬──────────┬─────────────┐
│ Column │ Type │ Modifiers │ Storage │ Description │
├──────────┼──────┼───────────┼──────────┼─────────────┤
│ ?column? │ text │ │ extended │ │
└──────────┴──────┴───────────┴──────────┴─────────────┘
View definition:
SELECT s."?column?"
FROM ( SELECT '2'::text
ORDER BY '2'::text) s;
Note the added cast to determine the type of the expression and the
generated column name.
If you dump/load that view definition, or even just execute the query
the fun starts:
postgres[1]=# SELECT s."?column?"
FROM ( SELECT '2'::text
ORDER BY '2'::text) s;
ERROR: column s.?column? does not exist
LINE 1: SELECT s."?column?
Due to the added explicit cast the generated column name now isn't
"?column?" but "text".
The easiest way to solve this would teach ruleutils.c to simply always
attach AS clauses for auto-generated columnnames. Won't look too pretty
though. Does somebody have a better idea?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
