On Tue, Nov 14, 2023 at 11:29 PM Nathan Bossart
wrote:
>
> On Tue, Nov 14, 2023 at 10:46:25PM +0530, Bharath Rupireddy wrote:
> > FWIW, there are other backward compatibility macros out there like
> > tuplestore_donestoring which was introduced by commit dd04e95 21 years
> > ago and SPI_push() and
On Wed, Nov 15, 2023 at 9:26 PM Nathan Bossart
wrote:
> On Wed, Nov 15, 2023 at 09:27:18AM +0530, Amul Sul wrote:
> > Nevermind, I usually use git apply or git am, here are those errors:
> >
> > PG/ - (master) $ git apply
> ~/Downloads/retire_compatibility_macro_v1.patch
> > error: patch failed:
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Nov 15, 2023 at 09:27:18AM +0530, Amul Sul wrote:
> Nevermind, I usually use git apply or git am, here are those errors:
>
> PG/ - (master) $ git apply ~/Downloads/retire_compatibility_macro_v1.patch
> error: patch failed: src/backend/access/brin/brin.c:297
> error: src/backend/access/brin
On Tue, Nov 14, 2023 at 9:21 PM Nathan Bossart
wrote:
> On Tue, Nov 14, 2023 at 04:25:24PM +0530, Amul Sul wrote:
> > Changes looks pretty much straight forward, but patch failed to apply on
> the
> > latest master head(b41b1a7f490) at me.
>
> Thanks for taking a look. Would you mind sharing the
On Tue, Nov 14, 2023 at 08:20:08PM +0100, Alvaro Herrera wrote:
> Oh, I don't. (But I wouldn't mind putting pg_attribute_deprecated to
> good use elsewhere ... not that I have any specific examples handy.)
Agreed.
> Your S key seems to be doing some funny business.
I seem to have accidentally e
On 2023-Nov-14, Nathan Bossart wrote:
> On Tue, Nov 14, 2023 at 12:10:41PM -0500, Tom Lane wrote:
> > FWIW, I think it's fine to just nuke MemoryContextResetAndDeleteChildren.
> > We ask extension authors to deal with much more significant API changes
> > than that in every release, and versions w
On Tue, Nov 14, 2023 at 10:46:25PM +0530, Bharath Rupireddy wrote:
> FWIW, there are other backward compatibility macros out there like
> tuplestore_donestoring which was introduced by commit dd04e95 21 years
> ago and SPI_push() and its friends which were made no-ops macros by
> commit 1833f1a 7 y
On Tue, Nov 14, 2023 at 12:10:41PM -0500, Tom Lane wrote:
> FWIW, I think it's fine to just nuke MemoryContextResetAndDeleteChildren.
> We ask extension authors to deal with much more significant API changes
> than that in every release, and versions where the updated code wouldn't
> work are long
On Tue, Nov 14, 2023 at 9:50 PM Alvaro Herrera wrote:
>
> On 2023-Nov-13, Nathan Bossart wrote:
>
> > Shall we retire this backwards compatibility macro at this point? A search
> > of https://codesearch.debian.net/ does reveal a few external uses, so we
> > could alternatively leave it around and
Nathan Bossart writes:
>> It might be worth introducing pg_attribute_deprecated() in c.h. I'm not
>> too worried about this particular macro, but it seems handy in general.
> Huh, this was brought up before [0].
> [0] https://postgr.es/m/20200825183002.fkvzxtneijsdgrfv%40alap3.anarazel.de
FWIW,
On Tue, Nov 14, 2023 at 11:01:15AM -0600, Nathan Bossart wrote:
> On Tue, Nov 14, 2023 at 04:36:44PM +, Dagfinn Ilmari Mannsåker wrote:
>> There's also __attribute__((deprecated)) (and and __declspec(deprecated)
>> for MSVC), but that can AFAIK only be attached to functions and
>> variables, no
On Tue, Nov 14, 2023 at 04:36:44PM +, Dagfinn Ilmari Mannsåker wrote:
> Is there a preprocessor symbol that is defined when building Postgres
> itself (and extensions in /contrib/), but not third-party extensions (or
> vice versa)? If so, the macro could be guarded by that, so that uses
> don'
Alvaro Herrera writes:
> On 2023-Nov-13, Nathan Bossart wrote:
>
>> Shall we retire this backwards compatibility macro at this point? A search
>> of https://codesearch.debian.net/ does reveal a few external uses, so we
>> could alternatively leave it around and just update Postgres to stop using
On Tue, Nov 14, 2023 at 05:20:16PM +0100, Alvaro Herrera wrote:
> Let's leave the macro around and just remove its uses in PGDG-owned
> code. Having the macro around hurts nothing, and we can remove it in 15
> years or so.
WFM
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On 2023-Nov-13, Nathan Bossart wrote:
> Shall we retire this backwards compatibility macro at this point? A search
> of https://codesearch.debian.net/ does reveal a few external uses, so we
> could alternatively leave it around and just update Postgres to stop using
> it, but I don't think it wou
On Tue, Nov 14, 2023 at 10:59:04AM -0500, Tom Lane wrote:
> Nathan Bossart writes:
>> On Tue, Nov 14, 2023 at 04:25:24PM +0530, Amul Sul wrote:
>>> Changes looks pretty much straight forward, but patch failed to apply on the
>>> latest master head(b41b1a7f490) at me.
>
>> Thanks for taking a look
Nathan Bossart writes:
> On Tue, Nov 14, 2023 at 04:25:24PM +0530, Amul Sul wrote:
>> Changes looks pretty much straight forward, but patch failed to apply on the
>> latest master head(b41b1a7f490) at me.
> Thanks for taking a look. Would you mind sharing the error(s) you are
> seeing? The patc
On Tue, Nov 14, 2023 at 04:25:24PM +0530, Amul Sul wrote:
> Changes looks pretty much straight forward, but patch failed to apply on the
> latest master head(b41b1a7f490) at me.
Thanks for taking a look. Would you mind sharing the error(s) you are
seeing? The patch applies fine on cfbot and my m
On Tue, Nov 14, 2023 at 12:30 AM Nathan Bossart
wrote:
> I just found myself researching the difference between MemoryContextReset()
> and MemoryContextResetAndDeleteChildren(), and it turns out that as of
> commit eaa5808 (2015), there is none.
> MemoryContextResetAndDeleteChildren() is just a b
I just found myself researching the difference between MemoryContextReset()
and MemoryContextResetAndDeleteChildren(), and it turns out that as of
commit eaa5808 (2015), there is none.
MemoryContextResetAndDeleteChildren() is just a backwards compatibility
macro for MemoryContextReset(). I found t
21 matches
Mail list logo
