Bug #734: Rename column make views go bad
Dennis Bj�rklund (db@zigo.dhs.org) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
Rename column make views go bad
Long Description
When I rename a column postgres seems to update the views. Or at least the views works after the update. But if I dump the database (with pg_dump) then I can not restore it since the dumped views still refer to the old column name.
I use postgresql 7.2.1.
If the view had not worked directly after the rename I would not have been surprised (there are other changes that have that effect). But that everything works until you try to restore was a bit surprising.
Sample Code
CREATE TABLE foo (
a integer
);
INSERT INTO foo VALUES (1);
INSERT INTO foo VALUES (2);
CREATE VIEW bar AS
SELECT a FROM foo;
-- See, it works
SELECT * FROM bar;
ALTER TABLE bar RENAME a TO b;
-- See, it still works
SELECT * FROM bar;
-- But the definition we see here is the old one
-- and this is the one that is going to be dumped.
-- Of course it can not be restored later when it
-- refers to the wrong column name
\d bar
No file was uploaded with this report
pgsql-bugs@postgresql.org writes:
When I rename a column postgres seems to update the views. Or at least
the views works after the update. But if I dump the database (with
pg_dump) then I can not restore it since the dumped views still refer
to the old column name.
Although you only see the effects in pg_dump, this is actually a backend
problem (pg_dump depends on pg_get_viewdef(), which wasn't being careful
about this situation).
I've committed fixes into current CVS for this, but I don't think there
will be a back-patch for 7.2 ... the risk of breaking other cases is
too high to put it out without a normal beta-test cycle.
regards, tom lane
I have some other problems with my dumps that stops them from being
restored later. It seems like functions and views are exported in the
wrong order.
pg_dump is pretty weak in that area --- someone needs to rewrite it to
take advantage of the dependency info that the backend now maintains,
rather than relying on OID ordering as it largely does now.
But if you can generate a reproducible example, send it in.
regards, tom lane
Import Notes
Reply to msg id not found: Pine.LNX.4.44.0208081936300.10819-100000@zigo.dhs.orgReference msg id not found: Pine.LNX.4.44.0208081936300.10819-100000@zigo.dhs.org | Resolved by subject fallback
Just want to validate this one.
Hitting TAB while editing a line crashes PSQL.
File completion is meaningless here.
What is it supposed to complete any way?
JLL
P.S. on 7.2.1
Import Notes
Reference msg id not found: Pine.LNX.4.44.0208081936300.10819-100000@zigo.dhs.org
Jean-Luc Lachance <jllachan@nsd.ca> writes:
Hitting TAB while editing a line crashes PSQL.
Not here.
Perhaps you have a broken libreadline library...
regards, tom lane
Tom,
I believe not. This is the error message I get.
psql: relocation error: psql: undefined symbol: rl_completion_matches
Tom Lane wrote:
Jean-Luc Lachance <jllachan@nsd.ca> writes:
Hitting TAB while editing a line crashes PSQL.
Not here.
Perhaps you have a broken libreadline library...
regards, tom lane
psql: relocation error: psql: undefined symbol: rl_completion_matches
Import Notes
Reference msg id not found: Pine.LNX.4.44.0208081936300.10819-100000@zigo.dhs.org
Jean-Luc Lachance <jllachan@nsd.ca> writes:
I believe not. This is the error message I get.
psql: relocation error: psql: undefined symbol: rl_completion_matches
That is a pretty common symptom of readline configuration problems.
Are you sure you built psql against readline header files that match
the installed readline library file?
regards, tom lane