Some more function-default issues

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Some more function-default issues
Date: 2009-01-06 13:32:44
Message-ID: 7958.1231248764@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Some further reflection about Rushabh Lathia's bug report of yesterday
led me to the realization that there's a pretty big hole in the function
defaults patch. Since we add default values during planning, it doesn't
work for any expression that's not fed through the planner. For
instance, ALTER COLUMN USING:

regression=# create function add(int, int = 42) returns int
regression-# as 'select $1+$2' language sql;
CREATE FUNCTION
regression=# create table foo(f1 int);
CREATE TABLE
regression=# insert into foo values (1);
INSERT 0 1
regression=# alter table foo alter column f1 type bigint using add(f1)::bigint;
ERROR: no value found for parameter 2
CONTEXT: SQL function "add" statement 1

The minimum-code-change solution would be to run around and try to make
sure every such expression gets passed through eval_const_expressions()
before we try to execute it. This is probably doable (looking for calls
to fix_opfuncids would be a good guide) but it seems like the potential
for errors of omission is large, particularly in third-party add-ons.

I wonder if anyone has an idea for a better way to attack this?

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gurjeet Singh 2009-01-06 13:38:21 Re: [HACKERS] ERROR: failed to find conversion function from "unknown" to text
Previous Message KaiGai Kohei 2009-01-06 13:28:16 Re: Updates of SE-PostgreSQL 8.4devel patches (r1389)