Re: Table Partitioning

After postgresql 11, it is possible to update the partitioning key and the
affected rows are moved to a valid partition under the hood. So I think the
best approach is to upgrade your PG version.

Regards

El mar, 19 ene 2021 a las 10:15, Amit jain (<amit7(dot)jain(at)gmail(dot)com>)
escribió:

> I am totally agree with Keith opinion on better to go Upgrade rather than
> managing partitioning code.
>
> Even PG version 11 has lot of partitioning features over older one, was
> written a blog on same, can have a glance.
>
> https://severalnines.com/database-blog/how-take-advantage-new-partitioning-features-postgresql-11
>
>
> On Tue, Jan 19, 2021 at 7:03 PM Keith Fiske <keith(dot)fiske(at)crunchydata(dot)com>
> wrote:
>
>>
>>
>> On Tue, Jan 19, 2021 at 7:12 AM hubert depesz lubaczewski <
>> depesz(at)depesz(dot)com> wrote:
>>
>>> On Tue, Jan 19, 2021 at 12:01:12PM +0000, Anjul Tyagi wrote:
>>> > Can we handle that in DB side with trigger?
>>>
>>> I don't think so. At least not easily.
>>>
>>> You could make a function to do so, though.
>>>
>>> Best regards,
>>>
>>> depesz
>>>
>>>
>>>
>>>
>> As depesz said, a trigger is possible, but very tricky. I was never able
>> to find a good trigger-based, solution to these kinds of updates for
>> pg_partman myself. Thankfully support for updates that move data between
>> child tables was added for native partitioning in PG11. I would highly
>> suggest planning an upgrade to your major version of PG. Skip 11 and go
>> right to 12 or 13. An upgrade would be arguably easier than trying to code
>> this yourself. And the added features to native partitioning in 11 and
>> above will make managing them far better in the long run.
>>
>> --
>> Keith Fiske
>> Senior Database Engineer
>> Crunchy Data - http://crunchydata.com
>>
>