Skip site navigation (1) Skip section navigation (2)

Re: [7.4.2] Still "variable not found in subplan target lists"

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "veramente(at)libero(dot)it" <veramente(at)libero(dot)it>,pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: [7.4.2] Still "variable not found in subplan target lists"
Date: 2004-04-18 10:50:51
Message-ID: 40825D8B.4080802@pse-consulting.de (view raw or flat)
Thread:
Lists: pgsql-bugs
Tom Lane wrote:

>It doesn't fix views that contain references to the column.  The new
>typmod would need to be propagated into the view's rule parsetree, and
>perhaps to the type of the view's result column if the view directly
>exposes the changed column (whereupon you need to recursively look at
>the views that depend on this one, etc).
>
>What you could probably do is find the referencing views via pg_depend.
>For each one, try to do CREATE OR REPLACE VIEW using the view definition
>string from pg_get_viewdef.  If it succeeds you're done (the variable
>must not be propagated to any output column).  If it fails, adjust the
>indicated output column's typmod.  Lather, rinse, repeat in case there
>is more than one dependent output column.  Recurse once you've
>successfully altered the view.
>
>It'd probably also be a smart idea to error out if pg_depend shows any
>dependencies on the column from objects that you don't know what to do
>with (aren't views).
>
>I recall there was some discussion of this stuff on pgsql-hackers the
>last time it was proposed to support "ALTER COLUMN type".  We may have
>thought of some additional considerations besides views.  I'd suggest
>trawling the list archives to see...
>
>  
>
There was discussion about altering type, mostly about changing beween 
binary incompatible types (e.g. int4->numeric) requiring adding/dropping 
columns and deep recreation of dependent objects.
There was a thread stating that a limited class of changes exist that 
can be done without deep impact, namely changing between binary 
compatible types and extending the length. This is what pgadmin3 does, 
but apparently this wasn't correct.


Regards,
Andreas


In response to

pgsql-bugs by date

Next:From: PostgreSQL Bugs ListDate: 2004-04-18 19:04:08
Subject: BUG #1135: integer::bit returns incorrect results
Previous:From: PostgreSQL Bugs ListDate: 2004-04-18 09:52:04
Subject: BUG #1134: ALTER USER ... RENAME breaks md5 passwords

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group