Re: A doubt about a newly added errdetail

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: alvherre(at)alvh(dot)no-ip(dot)org
Cc: amit(dot)kapila16(at)gmail(dot)com, houzj(dot)fnst(at)fujitsu(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: A doubt about a newly added errdetail
Date: 2022-09-28 09:41:10
Message-ID: 20220928.184110.1203373920993934359.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Wed, 28 Sep 2022 10:46:41 +0200, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote in
> On 2022-Sep-28, Amit Kapila wrote:
>
> > On Wed, Sep 28, 2022 at 11:30 AM Kyotaro Horiguchi
> > <horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
> > > It looks tome that the errmsg and errordetail are reversed. Isn't the following order common?
> > >
> > > > errmsg("schemas cannot be added to or dropped from publication \"%s\".",
> > > > NameStr(pubform->pubname)),
> > > > errdetail("The publication is defined as FOR ALL TABLES.")));
> > >
> >
> > This one seems to be matching with the below existing message:
> > ereport(ERROR,
> > (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
> > errmsg("publication \"%s\" is defined as FOR ALL TABLES",
> > NameStr(pubform->pubname)),
> > errdetail("Tables cannot be added to or dropped from FOR ALL TABLES
> > publications.")));
>
> Well, that suggests we should change both together. I do agree that
> they look suspicious; they should be more similar to this other one, I
> think:

Ah, yes, and thanks.

> ereport(ERROR,
> errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> errmsg("cannot add schema to publication \"%s\"",
> stmt->pubname),
> errdetail("Schemas cannot be added if any tables that specify a column list are already part of the publication."));
>
> The errcodes appear not to agree with each other, also. Maybe that
> needs some more thought as well. I don't think INVALID_PARAMETER_VALUE
> is the right thing here, and I'm not sure about
> OBJECT_NOT_IN_PREREQUISITE_STATE either.

The latter seems to fit better than the current one. That being said
if we change the SQLSTATE for exising erros, that may make existing
users confused.

> FWIW, the latter is a whole category which is not defined by the SQL
> standard, so I recall Tom got it from DB2. DB2 chose to subdivide in a
> lot of different cases, see
> https://www.ibm.com/docs/en/db2/9.7?topic=messages-sqlstate#rsttmsg__code55
> for a (current?) table. Maybe we should define some additional 55Pxx
> values -- say 55PR1 INCOMPATIBLE PUBLICATION DEFINITION (R for
> "replication"-related matters; the P is what we chose for the
> Postgres-specific subcategory).

I generally agree to this. But we don't have enough time to fully
consider that?

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2022-09-28 10:25:12 Obsolete comment in ExecInsert()
Previous Message Bharath Rupireddy 2022-09-28 09:30:30 Re: Avoid memory leaks during base backups