jian he writes:
> On Wed, Apr 24, 2024 at 5:47 PM Yugo NAGATA wrote:
>> This message was introduced by 278cb434110 which was aiming to
>> standardize the wording for similar errors. We can find the pattern
>> "missing {support function | operator} %d(%u,%u) in opfamily %u"
>> in several places.
On Wed, Apr 24, 2024 at 5:47 PM Yugo NAGATA wrote:
>
> On Wed, 24 Apr 2024 15:05:00 +0800
> jian he wrote:
>
> > hi.
> >
> > in make_pathkey_from_sortinfo
> >
> > equality_op = get_opfamily_member(opfamily,
> > opcintype,
> > opcintype,
> > BTEqualStrategyNumber);
> > if (!OidIsValid(equali
On Wed, 24 Apr 2024 15:05:00 +0800
jian he wrote:
> hi.
>
> in make_pathkey_from_sortinfo
>
> equality_op = get_opfamily_member(opfamily,
> opcintype,
> opcintype,
> BTEqualStrategyNumber);
> if (!OidIsValid(equality_op)) /* shouldn't happen */
> elog(ERROR, "missing operator %d(%u,%u) in
hi.
in make_pathkey_from_sortinfo
equality_op = get_opfamily_member(opfamily,
opcintype,
opcintype,
BTEqualStrategyNumber);
if (!OidIsValid(equality_op)) /* shouldn't happen */
elog(ERROR, "missing operator %d(%u,%u) in opfamily %u",
BTEqualStrategyNumber, opcintype, opcintype, opfamily);
On Tue, 28 Jan 2020 at 18:13, Amit Kapila wrote:
>
> On Sat, Jan 25, 2020 at 10:16 AM Amit Kapila wrote:
> >
> > On Fri, Jan 24, 2020 at 9:37 PM Tom Lane wrote:
> > >
> > > Amit Kapila writes:
> > > > LGTM. I have combined them into the single patch. What do we think
> > > > about backpatchin
On Sat, Jan 25, 2020 at 10:16 AM Amit Kapila wrote:
>
> On Fri, Jan 24, 2020 at 9:37 PM Tom Lane wrote:
> >
> > Amit Kapila writes:
> > > LGTM. I have combined them into the single patch. What do we think
> > > about backpatching this?
> >
> > No objection to the patch for HEAD, but it does no
On Fri, Jan 24, 2020 at 12:22 AM Amit Kapila wrote:
> One thing to note is that there are places in code where we use
> 'table' instead of 'relation' for the same thing in the error messages
> as seen in the below places (the first one uses 'relation', the second
> one uses 'table') and the patch
On Fri, Jan 24, 2020 at 9:37 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > LGTM. I have combined them into the single patch. What do we think
> > about backpatching this?
>
> No objection to the patch for HEAD, but it does not seem like
> back-patch material: it is not fixing a bug.
>
Okay, I
Amit Kapila writes:
> LGTM. I have combined them into the single patch. What do we think
> about backpatching this?
No objection to the patch for HEAD, but it does not seem like
back-patch material: it is not fixing a bug.
regards, tom lane
On Thu, Jan 23, 2020 at 5:51 PM Mahendra Singh Thalor
wrote:
>
> I fixed above comment and updated expected .out files. Attaching
> updated patches.
>
LGTM. I have combined them into the single patch. What do we think
about backpatching this? As there are quite a few changes in the
regression
On Thu, 23 Jan 2020 at 10:20, Amit Kapila wrote:
>
> On Wed, Jan 22, 2020 at 8:48 PM Tom Lane wrote:
> >
> > Alvaro Herrera writes:
> > > I wonder if we shouldn't be using errtablecol() here instead of (in
> > > addition to?) patching the errmsg() to include the table name.
> >
> > > Discussion:
On Wed, Jan 22, 2020 at 8:48 PM Tom Lane wrote:
>
> Alvaro Herrera writes:
> > I wonder if we shouldn't be using errtablecol() here instead of (in
> > addition to?) patching the errmsg() to include the table name.
>
> > Discussion: If we really like having the table names in errtable(), then
> >
On Wed, Jan 22, 2020 at 3:23 PM MBeena Emerson wrote:
>
> > -
> > 14. src/backend/commands/tablecmds.c
> >
> > 5310 else
> > 5311 ereport(ERROR,
> > 5312
Alvaro Herrera writes:
> I wonder if we shouldn't be using errtablecol() here instead of (in
> addition to?) patching the errmsg() to include the table name.
> Discussion: If we really like having the table names in errtable(), then
> we should have psql display it by default, and other tools wil
I wonder if we shouldn't be using errtablecol() here instead of (in
addition to?) patching the errmsg() to include the table name.
Discussion: If we really like having the table names in errtable(), then
we should have psql display it by default, and other tools will follow
suit; in that case we s
Hi Mahendra,
Thanks for working on this.
On Wed, 22 Jan 2020 at 13:26, Mahendra Singh Thalor wrote:
>
> On Tue, 21 Jan 2020 at 10:51, Amit Kapila wrote:
> >
> > On Mon, Jan 6, 2020 at 6:31 PM Mahendra Singh Thalor
> > wrote:
> > >
> > > On Sat, 6 Jul 2019 at 09:53, Amit Kapila wrote:
> > > >
On Tue, 21 Jan 2020 at 10:51, Amit Kapila wrote:
>
> On Mon, Jan 6, 2020 at 6:31 PM Mahendra Singh Thalor
wrote:
> >
> > On Sat, 6 Jul 2019 at 09:53, Amit Kapila
wrote:
> > >
> > > On Mon, Jul 1, 2019 at 10:05 PM Alvaro Herrera <
alvhe...@2ndquadrant.com> wrote:
> > > >
> > > > Do we have an act
On Tue, 21 Jan 2020 at 20:09, Alvaro Herrera wrote:
>
> On 2020-Jan-21, MBeena Emerson wrote:
>
> > The usage of the function errtableconstraint seems only to set the
> > schema_name table_name constraint_name internally and not for display
> > purposes. As seen in the following two cases where th
On 2020-Jan-21, MBeena Emerson wrote:
> The usage of the function errtableconstraint seems only to set the
> schema_name table_name constraint_name internally and not for display
> purposes. As seen in the following two cases where the relation name is
> displayed using RelationGetRelationName and
Hi Amit,
On Tue, 21 Jan 2020 at 10:49, Amit Kapila wrote:
> On Thu, Jan 9, 2020 at 5:42 PM MBeena Emerson
> wrote:
> >
>
> Hi Beena,
>
> It is better to reply inline.
>
> > Hi Mahendra,
> >
> > Thanks for the patch.
> > I am not sure but maybe the relation name should also be added to the
> fol
On Mon, Jan 6, 2020 at 6:31 PM Mahendra Singh Thalor wrote:
>
> On Sat, 6 Jul 2019 at 09:53, Amit Kapila wrote:
> >
> > On Mon, Jul 1, 2019 at 10:05 PM Alvaro Herrera
> > wrote:
> > >
> > > Do we have an actual patch here?
> > >
> >
> > We have a patch, but it needs some more work like finding
On Thu, Jan 9, 2020 at 5:42 PM MBeena Emerson wrote:
>
Hi Beena,
It is better to reply inline.
> Hi Mahendra,
>
> Thanks for the patch.
> I am not sure but maybe the relation name should also be added to the
> following test case?
>
> create table t4 (id int);
> insert into t4 values (1);
> AL
Hi Mahendra,
Thanks for the patch.
I am not sure but maybe the relation name should also be added to the
following test case?
create table t4 (id int);
insert into t4 values (1);
ALTER TABLE t4 ADD CONSTRAINT c1 CHECK (id > 10) NOT VALID; -- succeeds
ALTER TABLE t4 VALIDATE CONSTRAINT c1;
*ERROR:
On Sat, 6 Jul 2019 at 09:53, Amit Kapila wrote:
>
> On Mon, Jul 1, 2019 at 10:05 PM Alvaro Herrera
wrote:
> >
> > Do we have an actual patch here?
> >
>
> We have a patch, but it needs some more work like finding similar
> places and change all of them at the same time and then change the
> tests
On Mon, Jul 1, 2019 at 10:05 PM Alvaro Herrera wrote:
>
> Do we have an actual patch here?
>
We have a patch, but it needs some more work like finding similar
places and change all of them at the same time and then change the
tests to adapt the same.
--
With Regards,
Amit Kapila.
EnterpriseDB:
Do we have an actual patch here?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Sun, Mar 24, 2019 at 11:23 PM Amit Kapila wrote:
> Fair point. Can such an error message change break any application?
> I see some cases where users have check based on Error Code, but not
> sure if there are people who have check based on error messages.
I'm sure there are -- in fact, I've
On Sun, Mar 24, 2019 at 7:11 PM Greg Steiner wrote:
>
> To me the error message that includes more detail is superior. Even though
> you can get the detail from the logs, it seems like it would much more
> convenient for it to be reported out via the error to allow
> users/applications to ident
On Sun, Mar 24, 2019 at 11:53 PM Simon Riggs wrote:
>
> On Sun, 24 Mar 2019 at 13:02, Amit Kapila wrote:
>>
>> I think we are inconsistent for a similar message at a few other
>> places as well. See, below two messages:
>>
>> column \"%s\" contains null values
>> column \"%s\" of table \"%s\" co
On Sun, 24 Mar 2019 at 13:02, Amit Kapila wrote:
> On Sat, Mar 23, 2019 at 4:33 AM Fabrízio de Royes Mello
> wrote:
> >
> > On Fri, Mar 22, 2019 at 2:25 PM Simon Riggs
> wrote:
> > >
> > > As noted by a PostgreSQL user to me, error messages for NOT NULL
> constraints are inconsistent - they do
To me the error message that includes more detail is superior. Even though
you can get the detail from the logs, it seems like it would much more
convenient for it to be reported out via the error to allow
users/applications to identify the problem relation without fetching logs.
I understand if th
On Sat, Mar 23, 2019 at 4:33 AM Fabrízio de Royes Mello
wrote:
>
> On Fri, Mar 22, 2019 at 2:25 PM Simon Riggs wrote:
> >
> > As noted by a PostgreSQL user to me, error messages for NOT NULL
> > constraints are inconsistent - they do not mention the relation name in the
> > message, as all othe
On Fri, Mar 22, 2019 at 2:25 PM Simon Riggs wrote:
>
> As noted by a PostgreSQL user to me, error messages for NOT NULL
constraints are inconsistent - they do not mention the relation name in the
message, as all other variants of this message do. e.g.
>
> postgres=# create table nn (id integer not
As noted by a PostgreSQL user to me, error messages for NOT NULL
constraints are inconsistent - they do not mention the relation name in the
message, as all other variants of this message do. e.g.
postgres=# create table nn (id integer not null);
CREATE TABLE
postgres=# insert into nn values (NULL
34 matches
Mail list logo
