pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Lakhin <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: Wed, 01 May 2024 10:08:43 -0400
Message-ID: <1944626.1714572523@sss.pgh.pa.us> (raw)
In-Reply-To: <548a47bc-87ae-b3df-c6a2-60b9966f808b@gmail.com>
References: <18449-f8248467aaa294d5@postgresql.org>
	<403599.1714268901@sss.pgh.pa.us>
	<548a47bc-87ae-b3df-c6a2-60b9966f808b@gmail.com>

Alexander Lakhin <exclusion@gmail.com> writes:
> I've discovered one more case, presumably as hard as the other ones:
> CREATE TABLE t(a int);
> CREATE PUBLICATION p FOR TABLE t WHERE (a > 0);
> ALTER TABLE t ALTER COLUMN a TYPE bigint;
> fails with:
> ERROR:  unexpected object depending on column: publication of table t in publication p

Hm.  We could fix this by introducing another single-purpose error
report, but I'm starting to think that that's failing to learn from
experience.  Who's to say that other column dependencies aren't
possible, now or in the future?  The only thing stopping us from
treating the default: case as a normal ERRCODE_FEATURE_NOT_SUPPORTED
error is that it might be hard to phrase the error message in a nice
way.  We already have a precedent for this being an acceptable
errdetail:

                    ereport(ERROR,
                            (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
                             errmsg("cannot alter type of a column used in a policy definition"),
                             errdetail("%s depends on column \"%s\"",
                                       getObjectDescription(&foundObject, false),
                                       colName)));

It doesn't seem too awful to me to write the errmsg as

                             errmsg("cannot alter type of a column used in a %s",
                                    get_object_class_descr(foundObject.classid)),

This'd fall foul of English a/an grammar rules for some object class
names, so maybe we should phrase it a bit differently; but I'm sure
translated messages commit worse grammar violations all the time.

			regards, tom lane





view thread (7+ messages)  latest in thread

Message-ID: <1944626.1714572523@sss.pgh.pa.us>
Permalink:  ../1944626.1714572523@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/1944626.1714572523@sss.pgh.pa.us

 · 

reply

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: <1944626.1714572523@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