On Wed, Oct 9, 2024 at 8:54 PM Michael Paquier wrote:
>
> Applied the previous patch after looking at it again.
> --
> Michael
AFAIK this brings my year-long "GUC names" thread to a conclusion.
Thanks, Michael for helping to get these last couple of patches
pushed, and thanks to everybody else w
On Tue, Oct 08, 2024 at 06:57:10PM +1100, Peter Smith wrote:
> As for what is left, I had made just the minimal patch to fix the
> known "IntervalStyle" problem, but that assumed prior knowledge of
> what were the only problem names in the first place. Your way is
> better -- to always use the reco
On Mon, Oct 7, 2024 at 3:22 PM Michael Paquier wrote:
>
> On Tue, Sep 10, 2024 at 05:11:13PM +1000, Peter Smith wrote:
> > I have rebased the two remaining patches. See v12 attached.
>
> I've looked over the patch set again, and applied 0002.
>
> 0001 could be more ambitious and more consistent, l
On Tue, Sep 10, 2024 at 05:11:13PM +1000, Peter Smith wrote:
> I have rebased the two remaining patches. See v12 attached.
I've looked over the patch set again, and applied 0002.
0001 could be more ambitious and more consistent, like:
- The GUC name coming from the table's record is only used for
On Wed, Sep 4, 2024 at 3:54 PM Michael Paquier wrote:
>
...
> 0001 and 0004 have been applied with these tweaks. I am still not
> sure about the changes for DateStyle and IntervalStyle in 0002 and
> 0003. Perhaps others have an opinion that could drive to a consensus.
>
Thanks for pushing the p
Hello Peter,
[ sorry for the kind of off-topic ]
17.05.2024 14:57, Peter Eisentraut wrote:
I committed your 0001 and 0002 now, with some small fixes.
There has also been quite a bit of new code, of course, since you posted your patches, so we'll probably find a few
more things that could use
On Wed, Sep 04, 2024 at 09:17:15AM +1000, Peter Smith wrote:
> I have merged the patches 0001-0004 as suggested. Please see v11 attachments.
Thanks.
It took me some time to go through the whole tree for more
inconsistencies.
In 0001, search_path was missing quotes in vacuumlo.c and oid2name.c.
N
On Tue, Sep 3, 2024 at 4:35 PM Michael Paquier wrote:
>
> On Tue, Sep 03, 2024 at 12:00:19PM +1000, Peter Smith wrote:
> > Here is the rebased patch set v10*. Everything is the same as before
> > except now there are only 7 patches instead of 8. The previous v9-0001
> > ("bool") patch no longer ex
On Tue, Sep 03, 2024 at 12:00:19PM +1000, Peter Smith wrote:
> Here is the rebased patch set v10*. Everything is the same as before
> except now there are only 7 patches instead of 8. The previous v9-0001
> ("bool") patch no longer exists because those changes are now already
> present in HEAD.
>
Hi.
The cfbot was reporting my patches needed to be rebased.
Here is the rebased patch set v10*. Everything is the same as before
except now there are only 7 patches instead of 8. The previous v9-0001
("bool") patch no longer exists because those changes are now already
present in HEAD.
I hope t
CFBot reported some failures, so I have attached the rebased patch set v9*.
I'm hopeful the majority of these might be pushed to avoid more rebasing...
==
Kind Regards,
Peter Smith.
Fujitsu Australia
v9-0001-Add-quotes-for-GUCs-bool.patch
Description: Binary data
v9-0005-Add-quotes-for-GU
On Tue, May 28, 2024 at 4:16 PM Peter Smith wrote:
>
...
>
> The new GUC quoting patches are separated by different GUC types only
> to simplify my processing of them.
>
> v7-0001 = Add quotes for GUCs - bool
> v7-0002 = Add quotes for GUCs - int
> v7-0003 = Add quotes for GUCs - real
> v7-0004 =
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 set
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 i
> 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 \"full_page_
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 p
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 dynamical
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. A
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 whe
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
CATALOG_VE
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 Australi
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].
- So
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 configuration
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 a
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 able
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
> > > > MixedCas
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
>> cha
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 th
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 reduce
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 wrong
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 wor
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 conta
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 s
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 configur
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. A
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" a
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 translation team d
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 post my findings today o
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 Australi
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 attribute/option
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 prefer
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 thin
On Thu, Nov 2, 2023 at 1:25 AM Tom Lane wrote:
>
> Daniel Gustafsson writes:
> > On 1 Nov 2023, at 10:22, Peter Smith wrote:
> >> One idea to achieve consistency might be to always substitute GUC
> >> names using a macro.
> >>
> >> #define GUC_NAME(s) ("\"" s "\"")
> >>
> >> ereport(ERROR, (errc
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 no
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
p
Daniel Gustafsson writes:
> On 1 Nov 2023, at 10:22, Peter Smith wrote:
>> One idea to achieve consistency might be to always substitute GUC
>> names using a macro.
>>
>> #define GUC_NAME(s) ("\"" s "\"")
>>
>> ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
>> errmsg("%s must be at l
> 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 ice
> 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 posix_fadvise(
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
68 matches
Mail list logo
