Gurjeet Singh <gurjeet@singh.im> writes:
> 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.
When I say that ecpglib is next door to unmaintained, I'm just stating
the facts on the ground; project policy is irrelevant. That situation
is not likely to change until somebody steps up to do (a lot of) work
on it, which is probably unlikely to happen unless we start getting
actual complaints from ECPG users. For the meantime, what's there now
seems to be satisfactory to whoever is using it ... which might be
nobody?
In any case, you don't have to look far to notice that some parts of
the tree are maintained far more actively than others. ecpglib is
just one of the more identifiable bits that's receiving little love.
The quality of the code under contrib/ is wildly variable, and even
the server code itself has backwaters. (For instance, the "bit" types,
which aren't even in the standard anymore; or the geometric types,
or "money".)
By and large, I don't see this unevenness of maintenance effort as
a problem. It's more like directing our limited resources into the
most useful places. Code that isn't getting worked on is either not
used at all by anybody, or it serves the needs of those who use it
well enough already. Since it's difficult to tell which of those
cases applies, removing code just because it's not been improved
lately is a hard choice to sell. But so is putting maintenance effort
into code that there might be little audience for. In the end we
solve this via the principle of "scratch your own itch": if somebody
is concerned enough about a particular piece of code to put their own
time into improving it, then great, it'll get improved.
> 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.
Deprecation would imply that we're planning to remove it, which
we are not.
regards, tom lane