Peter Eisentraut writes:
> On 26.09.22 19:34, Tom Lane wrote:
>> I think we can do this while still having reasonable type-safety
>> by adding AssertVariableIsOfTypeMacro() checks to the macros.
> (I had looked into AssertVariableIsOfTypeMacro() for an earlier variant
> of this patch, before I h
On 26.09.22 19:34, Tom Lane wrote:
I think we can do this while still having reasonable type-safety
by adding AssertVariableIsOfTypeMacro() checks to the macros.
An advantage of that solution is that we verify that the code
will be safe for a 32-bit build even in 64-bit builds. (Of
course, it's
step forward.)
0001 attached is what you committed, 0002 is a proposed delta
to fix the Fast macros.
regards, tom lane
commit 595836e99bf1ee6d43405b885fb69bb8c6d3ee23
Author: Peter Eisentraut
Date: Mon Sep 12 17:35:55 2022 +0200
Convert *GetDatum() and DatumGet*() macros
On 12.09.22 19:59, Peter Eisentraut wrote:
On 12.09.22 19:03, Julien Rouhaud wrote:
On Mon, Sep 12, 2022 at 05:59:09PM +0200, Peter Eisentraut wrote:
committed, thanks
FTR lapwing is complaining about this commit:
https://brekka.postgresql.org/cgi-bin/show_log.pl?nm=lapwing&dt=2022-09-12%201
On 12.09.22 19:03, Julien Rouhaud wrote:
On Mon, Sep 12, 2022 at 05:59:09PM +0200, Peter Eisentraut wrote:
committed, thanks
FTR lapwing is complaining about this commit:
https://brekka.postgresql.org/cgi-bin/show_log.pl?nm=lapwing&dt=2022-09-12%2016%3A40%3A18.
Snapper is also failing with s
Hi,
On Mon, Sep 12, 2022 at 05:59:09PM +0200, Peter Eisentraut wrote:
>
> committed, thanks
FTR lapwing is complaining about this commit:
https://brekka.postgresql.org/cgi-bin/show_log.pl?nm=lapwing&dt=2022-09-12%2016%3A40%3A18.
Snapper is also failing with similar problems:
https://brekka.postg
On 08.09.22 11:26, Aleksander Alekseev wrote:
3. Go with your patch and just fix up the warnings about uninitialized
variables. But that seems the least principled to me.
IMO the 3rd option is the lesser evil. Initializing four bools/ints in
order to make Clang 11 happy doesn't strike me as su
Hi Peter,
> > 3. Go with your patch and just fix up the warnings about uninitialized
> > variables. But that seems the least principled to me.
>
> IMO the 3rd option is the lesser evil. Initializing four bools/ints in
> order to make Clang 11 happy doesn't strike me as such a big deal. At
> least
Hi Peter,
> Which compiler is that, by the way?
The warnings were reported by cfbot during the "clang_warning" step.
According to the logs:
```
using compiler=Debian clang version 11.0.1-2
```
Personally I use Clang 14 on MacOS and I don't get these warnings.
> I think to resolve that we could
On 30.08.22 20:15, Aleksander Alekseev wrote:
Here is v3 with silenced compiler warnings.
Some more warnings were reported by cfbot, so here is v4. Apologies
for the noise.
Looking at these warnings you are fixing, I think there is a small
problem we need to address.
I have defined Pointer
Hi hackers,
> Here is v3 with silenced compiler warnings.
Some more warnings were reported by cfbot, so here is v4. Apologies
for the noise.
--
Best regards,
Aleksander Alekseev
v4-0001-Fix-incorrect-uses-of-Datum-conversion-macros.patch
Description: Binary data
v4-0002-Convert-GetDatum-and
Hi hackers,
> Cfbot is making its mind at the moment of writing.
Here is v3 with silenced compiler warnings.
--
Best regards,
Aleksander Alekseev
v3-0002-Convert-GetDatum-and-DatumGet-macros-to-inline-fu.patch
Description: Binary data
v3-0001-Fix-incorrect-uses-of-Datum-conversion-macros.pa
Aleksander Alekseev writes:
> Maybe we should consider backporting at least 0001 patch, partially
> perhaps? I believe if fixes pretty cursed pieces of code, e.g:
Certainly if there are any parts of it that fix actual bugs,
we ought to backport those. I'm not in a big hurry to backport
cosmetic
On Tue, Aug 30, 2022 at 10:25 AM Aleksander Alekseev
wrote:
> > Yeah, I don't see a reason to back-patch a change like this
>
> Maybe we should consider backporting at least 0001 patch, partially
> perhaps? I believe if fixes pretty cursed pieces of code, e.g:
>
> ```
> pg_cryptohash_
Tom, Robert,
> Yeah, I don't see a reason to back-patch a change like this
Maybe we should consider backporting at least 0001 patch, partially
perhaps? I believe if fixes pretty cursed pieces of code, e.g:
```
pg_cryptohash_ctx *context =
-(pg_cryptohash_ctx *) PointerGe
On Tue, Aug 30, 2022 at 10:13 AM Tom Lane wrote:
> Aleksander Alekseev writes:
> > Just to clarify, a break in this case is going to be the fact that we
> > are adding new functions, although inlined, correct? Or maybe
> > something else? I'm sorry this is the first time I encounter the
> > quest
Aleksander Alekseev writes:
> Just to clarify, a break in this case is going to be the fact that we
> are adding new functions, although inlined, correct? Or maybe
> something else? I'm sorry this is the first time I encounter the
> question of ABI compatibility in the context of Postgres, so I wo
Hi Tom,
> Do you think this should be backported?
>> Impossible, it's an ABI break.
OK, got it.
Just to clarify, a break in this case is going to be the fact that we
are adding new functions, although inlined, correct? Or maybe
something else? I'm sorry this is the first time I encounter the
que
Aleksander Alekseev writes:
> Do you think this should be backported?
Impossible, it's an ABI break.
regards, tom lane
Hi Peter,
> To address this, I converted these macros to inline functions
This is a great change!
I encountered passing the wrong arguments to these macros many times,
and this is indeed pretty annoying. I wish we could forbid doing other
stupid things as well, e.g. comparing two Datum's directl
ndler(fcinfo);
else if (CALLED_AS_EVENT_TRIGGER(fcinfo))
{
plperl_event_trigger_handler(fcinfo);
--
2.37.1
From a54a726eadcab016714b431b23d273d9653fb2f6 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Sun, 28 Aug 2022 10:47:38 +0200
Subject: [PATCH 2/2]
21 matches
Mail list logo
