From: Tom Lane <tgl@sss.pgh.pa.us>
To: exclusion@gmail.com
Cc: pgsql-bugs@lists.postgresql.org, Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Subject: Re: BUG #18449: Altering column type fails when an SQL routine depends on the column
Date: Sat, 27 Apr 2024 21:48:21 -0400
Message-ID: <403599.1714268901@sss.pgh.pa.us> (raw)
In-Reply-To: <18449-f8248467aaa294d5@postgresql.org>
References: <18449-f8248467aaa294d5@postgresql.org>
PG Bug reporting form <noreply@postgresql.org> writes:
> The following script:
> CREATE TABLE t(a int, b varchar);
> CREATE FUNCTION f(i int) RETURNS text LANGUAGE SQL
> RETURN (SELECT b FROM t WHERE a = $1);
> ALTER TABLE t ALTER COLUMN b TYPE text;
> fails with:
> ERROR: unexpected object depending on column: function f(integer)
> on REL_14_STABLE .. master since e717a9a18.
Thanks for the report. It looks like most of the other hard cases
in RememberAllDependentForRebuilding just error out with code
along the lines of
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot alter type of a column used by a view or rule"),
I'm inclined to do likewise for functions. We could imagine trying
to re-parse the function definition against the new column type,
but there are way too many ways for that to go wrong. Just for
starters, there are possibly-security-grade hazards if the current
search_path isn't what it was when the function was created. There's
no guarantee that we'd succeed anyway, eg the new column type might
not work for some function or operator that's applied to it, and if
not the resulting error message would likely be very surprising.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, exclusion@gmail.com, peter.eisentraut@enterprisedb.com
Subject: Re: BUG #18449: Altering column type fails when an SQL routine depends on the column
In-Reply-To: <403599.1714268901@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox