On 21.07.21 04:21, Michael Paquier wrote:
On Tue, Jul 20, 2021 at 05:08:53PM +0200, Peter Eisentraut wrote:
While reviewing the logical decoding of sequences patch, I found a few more
places that could be updated in the new style introduced by this thread.
See attached patch.
Those changes loo
On Tue, Jul 20, 2021 at 05:08:53PM +0200, Peter Eisentraut wrote:
> While reviewing the logical decoding of sequences patch, I found a few more
> places that could be updated in the new style introduced by this thread.
> See attached patch.
Those changes look fine. I am spotting one instance in
i
While reviewing the logical decoding of sequences patch, I found a few
more places that could be updated in the new style introduced by this
thread. See attached patch.
From 92a06ebfa6f856246c2642a4e45c5b2af69a911d Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Tue, 20 Jul 2021 16:28:4
On 02.07.21 18:10, Alvaro Herrera wrote:
On 2021-Jun-24, Peter Eisentraut wrote:
There might be room for some wordsmithing in a few places, but generally I
think this is complete.
This looks good to me. I am +0.1 on your proposal of "cannot have
triggers" vs Michael's "cannot create triggers
On 2021-Jun-24, Peter Eisentraut wrote:
> There might be room for some wordsmithing in a few places, but generally I
> think this is complete.
This looks good to me. I am +0.1 on your proposal of "cannot have
triggers" vs Michael's "cannot create triggers", but really I could go
with either. Mi
On 02.07.21 08:25, Michael Paquier wrote:
+ ereport(ERROR,
+ (errcode(ERRCODE_WRONG_OBJECT_TYPE),
+errmsg("ALTER action %s cannot be performed on relation
\"%s\"",
+ action_str, RelationGetRelationName(rel)),
+
On Thu, Jun 24, 2021 at 10:12:49AM +0200, Peter Eisentraut wrote:
> There might be room for some wordsmithing in a few places, but generally I
> think this is complete.
I have been looking at that, and it seems to me that you nailed it.
That's a nice improvement compared to the existing error hand
On 13.04.20 15:54, Peter Eisentraut wrote:
I'm not a fan of error messages like
relation "%s" is not a table, foreign table, or materialized view
It doesn't tell me what's wrong, it only tells me what else could have
worked. It's also tedious to maintain and the number of combinations
g
Peter Eisentraut writes:
> On 2020-04-15 02:15, Tom Lane wrote:
>> In the meantime could we at least say "ALTER TABLE action cannot
>> be performed"?
> We don't know whether ALTER TABLE was the command. For example, in one
> of the affected regression test cases, the command is ALTER VIEW.
May
On 2020-04-15 02:15, Tom Lane wrote:
In the meantime could we at least say "ALTER TABLE action cannot
be performed"?
We don't know whether ALTER TABLE was the command. For example, in one
of the affected regression test cases, the command is ALTER VIEW.
--
Peter Eisentraut http
On 2020-Apr-15, Robert Haas wrote:
> [good arguments]
I don't disagree with anything you said, and I don't have anything to
add for now.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, Apr 14, 2020 at 7:02 PM Alvaro Herrera wrote:
> On 2020-Apr-13, Robert Haas wrote:
> > + ereport(ERROR,
> > + (errcode(ERRCODE_WRONG_OBJECT_TYPE),
> > + errmsg("action cannot be performed on relation \"%s\"",
> > + RelationGetRelationName(rel)),
> >
> > Super-vague.
>
> Maybe, but note tha
Alvaro Herrera writes:
> On 2020-Apr-13, Robert Haas wrote:
>> + ereport(ERROR,
>> + (errcode(ERRCODE_WRONG_OBJECT_TYPE),
>> + errmsg("action cannot be performed on relation \"%s\"",
>> + RelationGetRelationName(rel)),
>>
>> Super-vague.
> Maybe, but note that the patch proposed to replace this
On 2020-Apr-13, Robert Haas wrote:
> + ereport(ERROR,
> + (errcode(ERRCODE_WRONG_OBJECT_TYPE),
> + errmsg("action cannot be performed on relation \"%s\"",
> + RelationGetRelationName(rel)),
>
> Super-vague.
Maybe, but note that the patch proposed to replace this current error
message:
ERROR:
On 2020-Apr-14, Michael Paquier wrote:
> On Mon, Apr 13, 2020 at 11:13:15AM -0400, Tom Lane wrote:
> > ERROR: cannot define statistics for relation "ti"
> > DETAIL: This operation is not supported for indexes.
> >
> > which still leaves implicit that "ti" is an index, but probably that's
> > s
On Mon, Apr 13, 2020 at 11:13:15AM -0400, Tom Lane wrote:
> Fixing this while avoiding your concern about proliferation of messages
> seems a bit difficult though. The best I can do after a couple minutes'
> thought is
>
> ERROR: cannot define statistics for relation "ti"
> DETAIL: "ti" is an i
On 4/13/20 11:13 AM, Tom Lane wrote:
>
> ERROR: cannot define statistics for relation "ti"
> DETAIL: This operation is not supported for indexes.
>
> which still leaves implicit that "ti" is an index, but probably that's
> something the user can figure out.
>
+1 for this. It's clear and succin
Peter Eisentraut writes:
> I'm not a fan of error messages like
> relation "%s" is not a table, foreign table, or materialized view
Agreed, they're not great.
> For example:
> -ERROR: relation "ti" is not a table, foreign table, or materialized view
> +ERROR: cannot define statistics for
On Mon, Apr 13, 2020 at 9:55 AM Peter Eisentraut
wrote:
> Attached is another attempt to improve this.
Nice effort. Most of these seem like clear improvements, but some I don't like:
+ errmsg("relation \"%s\" is of unsupported kind",
+ RelationGetRelationName(rel)),
+ errdetail_relkind(RelationG
I'm not a fan of error messages like
relation "%s" is not a table, foreign table, or materialized view
It doesn't tell me what's wrong, it only tells me what else could have
worked. It's also tedious to maintain and the number of combinations
grows over time.
This was discussed many yea
20 matches
Mail list logo
