On 5/30/25 03:17, Nikolay Samokhvalov wrote:
On Thu, Jun 6, 2024 at 5:31 AM Dmitry Dolgov <9erthali...@gmail.com
+1. The PostgreSQL ecosystem is surprisingly fragmented, when it comes
to quite essential components that happen to be outside of the core. But
of course it doesn't mean that there should be _one_ component of every
kind in core, more like it makes sense to have _one_ component available
out of the box (where the box is whatever form of PostgreSQL that gets
delivered to users, e.g. a distro package, container, etc.).
+1 too.
There is a huge reason to have a job scheduler in core – new partition
creation.
In my opinion, partitioning in Postgres needs more automation, and new
partition creation is a big missing piece. And it does require a scheduler.
I like pg_timetable a lot, but it's written in Go;
pg_cron is written in Go, and it's already present in most managed
Postgres platforms. Why not to bring it to Postgres core so we could
then use it to improve developer experience of dealing with partitioning?
I would say you should provide a reason why it is too difficult to stay
outside the core, such as pg_hint_plan or a similar feature.
In my opinion, the main reason to push an extension into contrib is if
it has a strong connection with the core API. But the scheduler seems as
far from the volatile API features as possible.
That's more, contrib extensions have essential priority to external
solutions and reduce development impulse in the area.
--
regards, Andrei Lepikhov
