From: | Gurjeet Singh <gurjeet(at)singh(dot)im> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jacob Champion <jchampion(at)timescale(dot)com>, Joseph Koshakow <koshy44(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: DecodeInterval fixes |
Date: | 2023-07-08 19:47:32 |
Message-ID: | CABwTF4VG-D-TLUHMGSoF2n81bubkmcxvV3J3P7M=UswVaM4q0g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 7, 2023 at 4:13 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-07-08 19:49:31 | Re: Cleaning up array_in() |
Previous Message | Heikki Linnakangas | 2023-07-08 19:38:31 | Re: Cleaning up array_in() |