Em qua., 13 de set. de 2023 às 22:32, Michael Paquier
escreveu:
> On Wed, Sep 13, 2023 at 08:14:11AM -0700, Jeff Davis wrote:
> > Looks good to me, thank you.
>
> Applied, then. Thanks.
>
Thank you Michael, for the commit.
best regards,
Ranier Vilela
On Wed, Sep 13, 2023 at 08:14:11AM -0700, Jeff Davis wrote:
> Looks good to me, thank you.
Applied, then. Thanks.
--
Michael
signature.asc
Description: PGP signature
On Wed, 2023-09-13 at 11:48 +0900, Michael Paquier wrote:
> Hmm. I see your point, one could be confused that the function name
> is the provider with this wording. How about that instead:
> ERROR: unsupported collprovider for %s: %c
>
> I've hidden that in a macro that uses __func__ as Jeff h
On Wed, Sep 13, 2023 at 09:59:22AM +0900, Kyotaro Horiguchi wrote:
> At Tue, 12 Sep 2023 09:03:27 +0900, Michael Paquier
> wrote in
> > On Mon, Sep 11, 2023 at 12:15:49PM -0700, Jeff Davis wrote:
> > > That's fine with me.
> >
> > Okay. Then, please find attached a v4 for HEAD and REL_16_STABL
On Tue, Sep 12, 2023 at 09:40:04PM -0300, Ranier Vilela wrote:
> I think that is not a good idea.
Hm? We already use __func__ across the tree even on Windows and
nobody has complained about that. Using a macro for the elog()
generated would be slightly more elegant, actually.
--
Michael
signat
At Tue, 12 Sep 2023 09:03:27 +0900, Michael Paquier wrote
in
> On Mon, Sep 11, 2023 at 12:15:49PM -0700, Jeff Davis wrote:
> > That's fine with me.
>
> Okay. Then, please find attached a v4 for HEAD and REL_16_STABLE.
For example, they result in the following message:
ERROR: unsupported col
Em ter., 12 de set. de 2023 às 17:51, Jeff Davis
escreveu:
> On Tue, 2023-09-12 at 09:03 +0900, Michael Paquier wrote:
> > On Mon, Sep 11, 2023 at 12:15:49PM -0700, Jeff Davis wrote:
> > > That's fine with me.
> >
> > Okay. Then, please find attached a v4 for HEAD and REL_16_STABLE.
>
> One ques
On Tue, 2023-09-12 at 09:03 +0900, Michael Paquier wrote:
> On Mon, Sep 11, 2023 at 12:15:49PM -0700, Jeff Davis wrote:
> > That's fine with me.
>
> Okay. Then, please find attached a v4 for HEAD and REL_16_STABLE.
One question: would it make sense to use __func__?
Other than that, looks good.
Em seg., 11 de set. de 2023 às 21:03, Michael Paquier
escreveu:
> On Mon, Sep 11, 2023 at 12:15:49PM -0700, Jeff Davis wrote:
> > That's fine with me.
>
> Okay. Then, please find attached a v4 for HEAD and REL_16_STABLE.
>
LGTM.
best regards,
Ranier Vilela
On Mon, Sep 11, 2023 at 12:15:49PM -0700, Jeff Davis wrote:
> That's fine with me.
Okay. Then, please find attached a v4 for HEAD and REL_16_STABLE.
--
Michael
diff --git a/src/backend/utils/adt/pg_locale.c b/src/backend/utils/adt/pg_locale.c
index aa9da99308..c02fa7b203 100644
--- a/src/backend/
On Mon, 2023-09-11 at 07:24 +0900, Michael Paquier wrote:
> I'm OK with enforcing COLLPROVIDER_LIBC in this path, but I also
> value
> consistency across all the error messages of this file. After
> sleeping on it, and as that's a set of elogs, "unsupported
> collprovider" is fine for me across th
On Sun, Sep 10, 2023 at 06:28:08PM -0300, Ranier Vilela wrote:
> +1
> But as Jeff mentioned, when the locale is NULL,
> the provider is known to be COLLPROVIDER_LIBC.
>
> I think we can use this to provide an error message,
> when the locale is NULL.
>
> What do you think about v3 attached?
This
Em sex., 8 de set. de 2023 às 03:24, Michael Paquier
escreveu:
> On Wed, Sep 06, 2023 at 07:57:03AM -0300, Ranier Vilela wrote:
> > I think no one objected.
>
> Looking closer, there is much more inconsistency in this file
> depending on the routine called. How about something like the v2
> atta
On Fri, 2023-09-08 at 15:24 +0900, Michael Paquier wrote:
> Looking closer, there is much more inconsistency in this file
> depending on the routine called. How about something like the v2
> attached instead to provide more context in the error message about
> the function called? Let's say, when
On Wed, Sep 06, 2023 at 07:57:03AM -0300, Ranier Vilela wrote:
> I think no one objected.
Looking closer, there is much more inconsistency in this file
depending on the routine called. How about something like the v2
attached instead to provide more context in the error message about
the function
Em seg., 4 de set. de 2023 às 11:27, Ranier Vilela
escreveu:
> Em dom., 3 de set. de 2023 às 22:01, Michael Paquier
> escreveu:
>
>> On Sat, Sep 02, 2023 at 09:13:11AM -0300, Ranier Vilela wrote:
>> > I tried to keep the same behavior as before.
>> > Note that if the locale equals COLLPROVIDER_L
Em dom., 3 de set. de 2023 às 22:01, Michael Paquier
escreveu:
> On Sat, Sep 02, 2023 at 09:13:11AM -0300, Ranier Vilela wrote:
> > I tried to keep the same behavior as before.
> > Note that if the locale equals COLLPROVIDER_LIBC,
> > the message to the user will be the same.
>
> -/* shouldn'
On Sat, Sep 02, 2023 at 09:13:11AM -0300, Ranier Vilela wrote:
> I tried to keep the same behavior as before.
> Note that if the locale equals COLLPROVIDER_LIBC,
> the message to the user will be the same.
-/* shouldn't happen */
-elog(ERROR, "unsupported collprovider: %c", locale->provide
Em sex., 1 de set. de 2023 às 17:17, Robert Haas
escreveu:
> On Fri, Sep 1, 2023 at 11:47 AM Ranier Vilela wrote:
> > If a null locale is reached in these paths.
> > elog will dereference a null pointer.
>
> True. That's sloppy coding.
>
> I don't know enough about this code to be sure whether t
On Fri, Sep 1, 2023 at 11:47 AM Ranier Vilela wrote:
> If a null locale is reached in these paths.
> elog will dereference a null pointer.
True. That's sloppy coding.
I don't know enough about this code to be sure whether the error
messages that you propose are for the best.
--
Robert Haas
EDB
Hi,
If a null locale is reached in these paths.
elog will dereference a null pointer.
best regards,
Ranier Vilela
0001-Avoid-a-possible-dereference-a-null-pointer.patch
Description: Binary data
21 matches
Mail list logo
