Problems with "pg.dropped" column after upgrade 9.5 to 9.6 - Mailing list pgsql-bugs

From Pavel Hanák
Subject Problems with "pg.dropped" column after upgrade 9.5 to 9.6
Date
Msg-id 83shraampf.fsf@is-it.eu
Whole thread Raw
Responses Re: Problems with "pg.dropped" column after upgrade 9.5 to 9.6
Re: Problems with "pg.dropped" column after upgrade 9.5 to 9.6
List pgsql-bugs
Hi,

I've got very the similar problem as described in the message
with the subject "got some errors after upgrade poestgresql from 9.5 to 9.6".

I'll try to describe this very strange behaviour.

I have a table A which has some "pg.dropped" attribute in
pg_attribute table. It looks like:
 select attname, attnum   from pg_attribute  where attrelid = A::regclass and attisdropped;
            attname            | attnum  -------------------------------+-------- ........pg.dropped.57........ |
57(1 row) 

Now, I create SQL function doing only update on this table
when the boolean parameter of the function is True:
 CREATE OR REPLACE FUNCTION _test_sql_update(in do_update boolean) RETURNS VOID LANGUAGE sql VOLATILE AS $$     update
A       set col = NULL      where do_update; $$; 

Now running:
 select _test_sql_update(False);

returns this error:
 ERROR:  table row type and query-specified row type do not match DETAIL:  Query provides a value for a dropped column
atordinal position 57. CONTEXT:  SQL function "_test_sql_update" statement 1 

If I don't use the parameter in "where" and instead I use the constant
False directly, everything works:
 CREATE OR REPLACE FUNCTION _test_sql_update(in do_update boolean) RETURNS VOID LANGUAGE sql VOLATILE AS $$     update
A       set col = NULL      where False; $$; 
 select _test_sql_update(False);
 SQL=#  _test_sql  ----------- (1 row)

If I define the function as plpgsql, everything is also working:
 CREATE OR REPLACE FUNCTION _test_plpgsql_update(in do_update boolean) RETURNS VOID LANGUAGE plpgsql VOLATILE AS $$
BEGIN   update A      set col = NULL    where do_update; END; $$; 


My conclusion is:

The problem occurs only under these circumstances:

- Postgresql 9.6 (no problem in 9.5)

- SQL function doing update

- There is a boolean parameter of the fucntion used in the update command and the table which is updated has some
attisdroppedattributes 

Can anybody explain what is the problem?

Thanks
Pavel



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #14408: Schema not found error when 2 or more indices declared on temporary table
Next
From: Victor Colborn
Date:
Subject: Re: BUG #14408: Schema not found error when 2 or more indices declared on temporary table