Re: DecodeInterval fixes - Mailing list pgsql-hackers

From Gurjeet Singh
Subject Re: DecodeInterval fixes
Date
Msg-id CABwTF4VG-D-TLUHMGSoF2n81bubkmcxvV3J3P7M=UswVaM4q0g@mail.gmail.com
Whole thread Raw
In response to Re: DecodeInterval fixes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: DecodeInterval fixes
List pgsql-hackers
On Fri, Jul 7, 2023 at 4:13 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> The ECPG datetime datatype support code has been basically unmaintained
> for years, and has diverged quite far at this point from the core code.

I was under the impression that anything in the postgresql.git
repository is considered core, and hence maintained as one unit, from
release to release. An example of this, to me, were all the contrib/*
modules.

> I wouldn't expect that a patch to the core code necessarily applies
> easily to ECPG, nor would I expect somebody patching the core to bother
> trying.

The above statement makes me think that only the code inside
src/backend/ is considered core. Is that the right assumption?

> Perhaps modernizing/resyncing that ECPG code would be a worthwhile
> undertaking, but it'd be a mighty large one, and I'm not sure about
> the size of the return.  In the meantime, benign neglect is the policy.

Benign neglect doesn't sound nice from a user's/consumer's
perspective. Can it be labeled (i.e. declared as such in docs) as
deprecated.

Knowing that the tool you use has now been deprecated would be a
better message for someone still using it, even if it was left marked
deprecated indefinitely. Discovering benign neglect for the tool you
depend on, from secondary sources (like this list, forums, etc.), does
not evoke a lot of confidence.

Best regards,
Gurjeet
http://Gurje.et



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Cleaning up array_in()
Next
From: Tom Lane
Date:
Subject: Re: Cleaning up array_in()