On Fri, May 17, 2024 at 9:57 PM Peter Eisentraut wrote:
>
> On 17.05.24 05:31, Peter Smith wrote:
> >> I think we should accept your two patches
> >>
> >> v6-0001-GUC-names-docs.patch
> >> v6-0002-GUC-names-add-quotes.patch
> >>
> >> which effectively everyone was in favor of and which seem to be
On Fri, May 17, 2024 at 9:57 PM Peter Eisentraut wrote:
>
> On 17.05.24 05:31, Peter Smith wrote:
> >> I think we should accept your two patches
> >>
> >> v6-0001-GUC-names-docs.patch
> >> v6-0002-GUC-names-add-quotes.patch
> >>
> >> which effectively everyone was in favor of and which seem to be
On 17.05.24 05:31, Peter Smith wrote:
I think we should accept your two patches
v6-0001-GUC-names-docs.patch
v6-0002-GUC-names-add-quotes.patch
which effectively everyone was in favor of and which seem to be the most
robust and sustainable solution.
(The remaining three patches from the v6
On Thu, May 16, 2024 at 9:35 PM Peter Eisentraut wrote:
>
> On 04.01.24 07:53, Peter Smith wrote:
> >> Now that I read this again, I think this is wrong.
> >>
> >> We should decide the quoting for a category, not the actual content.
> >> Like, quote all file names; do not quote keywords.
> >>
>
Daniel Gustafsson writes:
> On 16 May 2024, at 13:35, Peter Eisentraut wrote:
>> - errmsg("WAL generated with full_page_writes=off was replayed "
>> + errmsg("WAL generated with \"full_page_writes=off\" was replayed "
> I'm not a fan of this syntax, but I at the same time can't offer a better
> On 16 May 2024, at 13:56, Alvaro Herrera wrote:
> I think we should also take patch 0005 in pg17, which reduces the number
> of strings to translate.
Agreed, lessening the burden on translators is always a good idea.
--
Daniel Gustafsson
> On 16 May 2024, at 13:35, Peter Eisentraut wrote:
> I think we should accept your two patches
I agree with this.
> v6-0001-GUC-names-docs.patch
+1
> v6-0002-GUC-names-add-quotes.patch
- errmsg("WAL generated with full_page_writes=off was replayed "
+ errmsg("WAL generated with
On 2024-May-16, Peter Eisentraut wrote:
> I think we should accept your two patches
>
> v6-0001-GUC-names-docs.patch
> v6-0002-GUC-names-add-quotes.patch
>
> which effectively everyone was in favor of and which seem to be the most
> robust and sustainable solution.
I think we should also take
On 04.01.24 07:53, Peter Smith wrote:
Now that I read this again, I think this is wrong.
We should decide the quoting for a category, not the actual content.
Like, quote all file names; do not quote keywords.
This led to the attempted patch to decide the quoting of GUC parameter
names
On 21.12.23 07:24, Peter Smith wrote:
#1. GUC name quoting.
Some basic guidelines were decided and a patch is already pushed [1].
In messages containing configuration variable names, do not include quotes
when the names are visibly not natural English words, such as when they
Hi,
This thread seems to be a bit stuck, so I thought I would try to
summarize my understanding to hopefully get it moving again...
The original intent of the thread was just to introduce some
guidelines for quoting or not quoting GUC names in messages because
previously it seemed quite ad-hoc
On Thu, Dec 14, 2023 at 09:38:40AM +0100, Peter Eisentraut wrote:
> After these discussions, I think this rule change was not a good idea. It
> effectively enforces these kinds of inconsistencies. For example, if you
> ever refactored
>
> "DateStyle is wrong"
>
> to
>
> "%s is wrong"
>
On 11.12.23 00:07, Peter Smith wrote:
If the rule is changed to quote those MixedCase GUCs then the docs
will require minor tweaking
CURRENT
In messages containing configuration variable names, do not include quotes
when the names are visibly not natural English words, such as
On Mon, Dec 11, 2023 at 10:14:11AM +1100, Peter Smith wrote:
> This v5* looks good to me, except it will need some further
> modification if PeterE's suggestion [1] to keep quotes for the
> MixedCase GUCs is adopted.
-errdetail("The database cluster was initialized with
This v5* looks good to me, except it will need some further
modification if PeterE's suggestion [1] to keep quotes for the
MixedCase GUCs is adopted.
==
[1]
https://www.postgresql.org/message-id/9e7802b2-2cf2-4c2d-b680-b2ccb9db1d2f%40eisentraut.org
Kind Regards,
Peter Smith.
Futjisu
On Sat, Dec 9, 2023 at 1:48 AM Peter Eisentraut wrote:
>
> On 08.12.23 05:10, Peter Smith wrote:
> > Patch 0001 -- "datestyle" becomes DateStyle in messages
> > Rebased this again, which was part of an earlier patch set
> > - I think any GUC names documented as MixedCase should keep that same
> >
On 08.12.23 05:10, Peter Smith wrote:
Patch 0001 -- "datestyle" becomes DateStyle in messages
Rebased this again, which was part of an earlier patch set
- I think any GUC names documented as MixedCase should keep that same
case in messages; this also obeys the guidelines recently pushed [1].
-
On 2023-Dec-08, Peter Smith wrote:
> Patch 0001 -- "datestyle" becomes DateStyle in messages
> Rebased this again, which was part of an earlier patch set
> - I think any GUC names documented as MixedCase should keep that same
> case in messages; this also obeys the guidelines recently pushed [1].
On Fri, Dec 1, 2023 at 7:38 AM Peter Eisentraut wrote:
>
> On 30.11.23 06:59, Michael Paquier wrote:
> > ereport(elevel,
> > (errcode(ERRCODE_UNDEFINED_OBJECT),
> > - errmsg("unrecognized
On 30.11.23 06:59, Michael Paquier wrote:
ereport(elevel,
(errcode(ERRCODE_UNDEFINED_OBJECT),
-errmsg("unrecognized configuration parameter \"%s\"
in file \"%s\" line %d",
-
> +/*
> + * Return whether the GUC name should be enclosed in double-quotes.
> + *
> + * Quoting is intended for names which could be mistaken for normal English
> + * words. Quotes are only applied to GUC names that are written entirely
> with
> + * lower-case alphabetical characters.
> + */
On Thu, Nov 30, 2023 at 4:59 PM Michael Paquier wrote:
>
> On Tue, Nov 28, 2023 at 11:54:33AM +1100, Peter Smith wrote:
> > Here is patch set v3.
> >
> > Patches 0001 and 0002 are unchanged from v2.
>
> After some grepping, I've noticed that 0002 had a mistake with
> track_commit_timestamp: some
On Thu, Nov 30, 2023 at 03:29:49PM +0900, Kyotaro Horiguchi wrote:
> In this patch, the quotation marks cannot be changed from double
> quotes.
Indeed, that's a good point. I completely forgot about that.
--
Michael
signature.asc
Description: PGP signature
At Thu, 30 Nov 2023 14:59:21 +0900, Michael Paquier wrote
in
> > Patch 0003 now uses a "%s%s%s" format specifier with GUC_FORMAT macro
> > in guc.c, as recently suggested by Michael [1].
>
> I cannot think about a better idea as these strings need to be
> translated so they need three %s.
In
On Tue, Nov 28, 2023 at 11:54:33AM +1100, Peter Smith wrote:
> Here is patch set v3.
>
> Patches 0001 and 0002 are unchanged from v2.
After some grepping, I've noticed that 0002 had a mistake with
track_commit_timestamp: some alternate output of modules/commit_ts/
was not updated. meson was
On Tue, 2023-11-28 at 07:53 +0900, Michael Paquier wrote:
> On Mon, Nov 27, 2023 at 01:35:44AM -0500, Tom Lane wrote:
> > Laurenz Albe writes:
> > > On Mon, 2023-11-27 at 13:41 +1100, Peter Smith wrote:
> > > > In the documentation and in the guc_tables.c they are all described in
> > > >
Here is patch set v3.
Patches 0001 and 0002 are unchanged from v2.
Patch 0003 now uses a "%s%s%s" format specifier with GUC_FORMAT macro
in guc.c, as recently suggested by Michael [1].
~
(Meanwhile, the MixedCase stuff is still an open question, to be
addressed in a later patch version)
On Mon, Nov 27, 2023 at 01:35:44AM -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > On Mon, 2023-11-27 at 13:41 +1100, Peter Smith wrote:
>>> In the documentation and in the guc_tables.c they are all described in
>>> MixedCase (e.g. "DateStyle" instead of "datestyle"), so I felt the
>>> messages
Laurenz Albe writes:
> On Mon, 2023-11-27 at 13:41 +1100, Peter Smith wrote:
>> In the documentation and in the guc_tables.c they are all described in
>> MixedCase (e.g. "DateStyle" instead of "datestyle"), so I felt the
>> messages should use the same case the documentation, which is why I
>>
On Mon, 2023-11-27 at 13:41 +1100, Peter Smith wrote:
> TBH, I suspect something fishy about these mixed-case GUCs.
>
> In the documentation and in the guc_tables.c they are all described in
> MixedCase (e.g. "DateStyle" instead of "datestyle"), so I felt the
> messages should use the same case
On Mon, Nov 27, 2023 at 01:41:18PM +1100, Peter Smith wrote:
> TBH, I suspect something fishy about these mixed-case GUCs.
>
> In the documentation and in the guc_tables.c they are all described in
> MixedCase (e.g. "DateStyle" instead of "datestyle"), so I felt the
> messages should use the same
On Mon, Nov 27, 2023 at 12:44 PM Michael Paquier wrote:
>
> On Mon, Nov 27, 2023 at 10:04:35AM +1100, Peter Smith wrote:
> > On Fri, Nov 24, 2023 at 8:53 PM Alvaro Herrera
> > wrote:
> >> Yeah. Also, these could be changed to have the GUC name outside the
> >> message proper, which would
Michael Paquier writes:
> Is there a reason why we don't just use islower() or is that just to
> get something entirely local independent?
islower() and related functions are not to be trusted for this
purpose. They will certainly give locale-dependent results,
and they might give entirely
On Mon, Nov 27, 2023 at 10:04:35AM +1100, Peter Smith wrote:
> On Fri, Nov 24, 2023 at 8:53 PM Alvaro Herrera
> wrote:
>> Yeah. Also, these could be changed to have the GUC name outside the
>> message proper, which would reduce the total number of messages. (But
>> care must be given to the
On Fri, Nov 24, 2023 at 8:53 PM Alvaro Herrera wrote:
>
> On 2023-Nov-24, Michael Paquier wrote:
>
> > On Thu, Nov 23, 2023 at 06:27:04PM +1100, Peter Smith wrote:
> > > There may be some changes I've missed, but hopefully, this is a nudge
> > > in the right direction.
> >
> > Thanks for spending
On Fri, Nov 24, 2023 at 2:11 PM Michael Paquier wrote:
>
> On Thu, Nov 23, 2023 at 06:27:04PM +1100, Peter Smith wrote:
> > There may be some changes I've missed, but hopefully, this is a nudge
> > in the right direction.
>
> Thanks for spending some time on that.
>
>
> +In messages
On Fri, Nov 24, 2023 at 10:53:40AM +0100, Alvaro Herrera wrote:
> I think we could leave these improvements for a second round. They
> don't need to hold back the improvement we already have.
Of course, no problem here to do things one step at a time.
--
Michael
signature.asc
Description: PGP
On 2023-Nov-24, Michael Paquier wrote:
> On Thu, Nov 23, 2023 at 06:27:04PM +1100, Peter Smith wrote:
> > There may be some changes I've missed, but hopefully, this is a nudge
> > in the right direction.
>
> Thanks for spending some time on that.
+1
>
> +In messages containing
On Thu, Nov 23, 2023 at 06:27:04PM +1100, Peter Smith wrote:
> There may be some changes I've missed, but hopefully, this is a nudge
> in the right direction.
Thanks for spending some time on that.
+In messages containing configuration variable names, do not include quotes
+when the
On Thu, Nov 9, 2023 at 10:04 PM Alvaro Herrera wrote:
>
> On 2023-Nov-09, Peter Smith wrote:
>
> > Notice that NOT QUOTED is the far more common pattern, so my vote
> > would be just to standardise on making everything this way. I know
> > there was some concern raised about ambiguous words like
On 2023-Nov-09, Peter Smith wrote:
> Notice that NOT QUOTED is the far more common pattern, so my vote
> would be just to standardise on making everything this way. I know
> there was some concern raised about ambiguous words like "timezone"
> and "datestyle" etc but in practice, those are rare.
At Thu, 9 Nov 2023 12:55:44 +1100, Peter Smith wrote in
> The most common pattern there is "You might need to increase %s.".
..
> Here is a patch to modify those other similar variations so they share
> that common wording.
>
> PSA.
I'm uncertain whether the phrases "Consider doing something"
On Thu, Nov 2, 2023 at 1:25 AM Tom Lane wrote:
>
...
> Our error message style guidelines say not to assemble messages out
> of separate parts, because it makes translation difficult. Originally
> we applied that rule to GUC names mentioned in messages as well.
> Awhile ago the t
On Wed, Nov 8, 2023 at 7:40 AM Peter Smith wrote:
>
> FWIW, I am halfway through doing regex checking of the PG16 source for
> all GUC names in messages to see what current styles are in use today.
>
> Not sure if those numbers will influence the decision.
>
> I hope I can p
FWIW, I am halfway through doing regex checking of the PG16 source for
all GUC names in messages to see what current styles are in use today.
Not sure if those numbers will influence the decision.
I hope I can post my findings today or tomorrow.
==
Kind Regards,
Peter Smith.
Fujitsu
On Tue, Nov 07, 2023 at 10:33:03AM +0100, Alvaro Herrera wrote:
> On 2023-Nov-01, Nathan Bossart wrote:
>> +1, IMHO quoting GUC names makes it abundantly clear that they are special
>> identifiers. In de4d456, we quoted the role names in a bunch of messages.
>> We didn't quote the
Alvaro Herrera writes:
> On 2023-Nov-01, Nathan Bossart wrote:
>> +1, IMHO quoting GUC names makes it abundantly clear that they are special
>> identifiers. In de4d456, we quoted the role names in a bunch of messages.
>> We didn't quote the attribute/option names, but those are in all-caps, so
On 2023-Nov-01, Nathan Bossart wrote:
> On Wed, Nov 01, 2023 at 09:46:52PM +0100, Laurenz Albe wrote:
> > I agree for names with underscores in them. But I think that quoting
> > is necessary for names like "timezone" or "datestyle" that might be
> > mistaken for normal words. My personal
On Wed, Nov 01, 2023 at 09:46:52PM +0100, Laurenz Albe wrote:
> I agree for names with underscores in them. But I think that quoting
> is necessary for names like "timezone" or "datestyle" that might be
> mistaken for normal words. My personal preference is to always quote
> GUC names, but I
lly
> > add translator comments, but it's something to consider.
>
> Our error message style guidelines say not to assemble messages out
> of separate parts, because it makes translation difficult. Originally
> we applied that rule to GUC names mentioned in messages as well.
> Awh
On Wed, 2023-11-01 at 16:12 -0400, Peter Eisentraut wrote:
> On 01.11.23 10:25, Tom Lane wrote:
> > And there's never been any
> > real clarity about whether to quote GUC names, though certainly we're
> > more likely to quote anything injected with %s. So that's why we have
> > a mishmash right
On 01.11.23 10:25, Tom Lane wrote:
And there's never been any
real clarity about whether to quote GUC names, though certainly we're
more likely to quote anything injected with %s. So that's why we have
a mishmash right now.
I'm leaning toward not quoting GUC names. The quoting is needed in
little context about the message. We already have that today to some
> extent (so it might not be an issue), and it might be doable to automatically
> add translator comments, but it's something to consider.
Our error message style guidelines say not to assemble messages out
of separate parts
> On 1 Nov 2023, at 10:22, Peter Smith wrote:
>
> On Wed, Nov 1, 2023 at 8:02 PM Peter Smith wrote:
> ...
>>
>> I had intended to make a patch to address the inconsistency, but
>> couldn't decide which of those styles was the preferred one.
>>
>> Then I worried this could be the tip of the
> On 1 Nov 2023, at 10:02, Peter Smith wrote:
> GUC_check_errdetail("effective_io_concurrency must be set to 0 on
> platforms that lack posix_fadvise().");
> src/backend/commands/variable.c:
> GUC_check_errdetail("maintenance_io_concurrency must be set to 0 on
> platforms that lack
On Wed, Nov 1, 2023 at 8:02 PM Peter Smith wrote:
...
>
> I had intended to make a patch to address the inconsistency, but
> couldn't decide which of those styles was the preferred one.
>
> Then I worried this could be the tip of the iceberg -- GUC names occur
> in many other error messages where
Hi hackers,
While reviewing another patch I noticed how the GUCs are
inconsistently named within the GUC_check_errdetail messages:
==
below, the GUC name is embedded but not quoted:
src/backend/access/transam/xlogprefetcher.c:
GUC_check_errdetail("recovery_prefetch is not supported on
57 matches
Mail list logo
