Re: ALTERed DEFAULTS not visible to PL/pgSQL cached plans

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: ALTERed DEFAULTS not visible to PL/pgSQL cached plans
Date: 2006-03-12 17:29:08
Message-ID: 20060312172908.GB5301@surnet.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Josh Berkus wrote:

> Steps to Reproduce:
> (sample code attached)
> 1) Create a table.
> 2) Create a function which inserts a row into that table.
> 3) Run the function once.
> 4) ALTER the table with a new column and SET DEFAULT for that column.
> 5) Run the function again.
> 6) Re-load the function (via REPLACE)
> 7) Insert one more row using the function.
> 8) The table will have NULL values in the first TWO rows, not the first ONE
> row as it should. This is because the DEFAULT value is not being "seen"
> by the cached plan of the function.

I don't think this is really surprising, because the plan of the insert
query will be saved in the function parsetree. There is no way for the
function to notice that the default has changed with current
infrastructure, until we have the plan-dependency stuff in.

If this really harms you, you could use EXECUTE. Or reconnect after you
change the table, whatever.

create or replace function insert_bugtest (
vname text )
returns int as $f$
begin
execute $e$ insert into bugtest ( name ) values
($e$ || quote_literal(vname) || $e$) $e$;
return currval('bugtest_id_seq');
end; $f$ language plpgsql security definer;

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Alexander Kirpa 2006-03-12 22:26:02 BUG #2315: Crash engine after modify "active" function
Previous Message L.Jumadi 2006-03-12 05:03:10 BUG #2314: The Order changed?