Re: [GENERAL] replacing a view: bug or feature?

Is the error below a bug? Or a feature?

% cat foo.sql

SELECT version();
CREATE TABLE foo ( "key" serial NOT NULL PRIMARY KEY, msg character(100));
CREATE TABLE bar ( "key" serial NOT NULL PRIMARY KEY, msg character(100));
CREATE VIEW baz AS SELECT * FROM foo UNION ALL SELECT * FROM bar;
CREATE OR REPLACE VIEW baz AS SELECT * FROM foo;

% psql -e -f foo.sql
SELECT version();
version
---------------------------------------------------------------------------------------------------------
PostgreSQL 7.4.6 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.2
20030222 (Red Hat Linux 3.2.2-5)
(1 row)

CREATE TABLE foo ( "key" serial NOT NULL PRIMARY KEY, msg character(100));
psql:foo.sql:3: NOTICE: CREATE TABLE will create implicit sequence
"foo_key_seq" for "serial" column "foo.key"
psql:foo.sql:3: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit
index "foo_pkey" for table "foo"
CREATE TABLE
CREATE TABLE bar ( "key" serial NOT NULL PRIMARY KEY, msg character(100));
psql:foo.sql:4: NOTICE: CREATE TABLE will create implicit sequence
"bar_key_seq" for "serial" column "bar.key"
psql:foo.sql:4: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit
index "bar_pkey" for table "bar"
CREATE TABLE
CREATE VIEW baz AS SELECT * FROM foo UNION ALL SELECT * FROM bar;
CREATE VIEW
CREATE OR REPLACE VIEW baz AS SELECT * FROM foo;
psql:foo.sql:6: ERROR: cannot change data type of view column "msg"

"Ed L." <pgsql(at)bluepolka(dot)net> writes:
> CREATE TABLE foo ( "key" serial NOT NULL PRIMARY KEY, msg character(100));
> CREATE TABLE bar ( "key" serial NOT NULL PRIMARY KEY, msg character(100));
> CREATE VIEW baz AS SELECT * FROM foo UNION ALL SELECT * FROM bar;
> CREATE OR REPLACE VIEW baz AS SELECT * FROM foo;
> psql:foo.sql:6: ERROR: cannot change data type of view column "msg"

The bottom-line issue here is that a UNION sets the typmod of its output
columns to -1, even when the inputs all share the same type OID and
typmod. We changed that behavior some time ago for JOIN columns, and
probably ought to do the same for UNION columns.

I think this requires only a minor change in parser/analyze.c's
transformSetOperationStmt() ... any objections?

regards, tom lane