autogenerated column names + views are a dump hazard

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: kathy(dot)forte(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: autogenerated column names + views are a dump hazard
Date: 2015-03-02 20:57:59
Message-ID: 20150302205759.GF22160@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Qingqing Zhou 2015-03-02 21:00:31 Re: 32bit OID wrap around concerns
Previous Message Kevin Grittner 2015-03-02 20:47:04 Re: Idea: closing the loop for "pg_ctl reload"