On 2022-Sep-26, Amit Kapila wrote:
> On Mon, Sep 26, 2022 at 1:10 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> > ERROR: cannot use column list for relation "%s.%s" in publication "%s"
> > DETAIL: Column lists cannot be specified in publications containing FOR TABLES IN SCHEMA elements.
>
> This looks mostly good to me. BTW, is it a good idea to add ".. in
> publication "%s"" to the error message as this can happen even during
> create publication?
Hmm, I don't see why not. The publication is new, sure, but it would
already have a name, so there's no possible confusion as to what this
means.
(My main change was to take the word "publication" out of the phrase
"publication column list", because that seemed a bit strange; it isn't
the publication that has a column list, but the relation.)
> If so, I think we can change the nearby message as below to include
> the same:
>
> if (!pubviaroot &&
> pri->relation->rd_rel->relkind == RELKIND_PARTITIONED_TABLE)
> ereport(ERROR,
> (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> errmsg("cannot use publication column list for relation \"%s\"",
WFM.
> I think even if we don't include the publication name, there won't be
> any confusion because there won't be multiple publications in the
> command.
True, and the whole error report is likely to contain a STATEMENT line.
However, you could argue that specifying the publication in errmsg is
redundant. But then, the "for relation %s.%s" is also redundant (since
that is *also* in the STATEMENT line), and could even be misleading: if
you have a command that specifies *two* relations with column lists, why
specify only the first one you find? The user could be angry that they
remove the column list from that relation and retry, and then receive
the exact same error for the next relation with a list that they didn't
edit. But I think people don't work that way. So if you wanted to be
super precise you would also omit the relation name unless you scanned
the whole list and verified that only this relation is specifying a
column list; but whom does that help?
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/