Re: unsupportable composite type partition keys - Mailing list pgsql-hackers

From Amit Langote
Subject Re: unsupportable composite type partition keys
Date
Msg-id CA+HiwqHoNKn3HBb0yZ9sCZu=GL_KxrXAFiYygLTgS95DBOcZTw@mail.gmail.com
Whole thread Raw
In response to Re: unsupportable composite type partition keys  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: unsupportable composite type partition keys
List pgsql-hackers
On Tue, Dec 24, 2019 at 6:33 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
> > One thing I see is that you chose to relocate RelationGetPartitionDesc's
> > declaration to partdesc.h, whereupon RelationBuildPartitionDesc doesn't
> > have to be exported at all anymore.  Perhaps that's a better factorization
> > than what I did.  It supposes that any caller of RelationGetPartitionDesc
> > is going to need partdesc.h, but that seems reasonable.  We could likewise
> > move RelationGetPartitionKey to partcache.h.
>
> I concluded that that is indeed a better solution; it does allow removing
> some rel.h inclusions (though possibly those were just duplicative?), and
> it also means that relcache.c itself doesn't need any partitioning
> inclusions at all.
>
> Here's a cleaned-up patch that does it like that and also fixes the
> memory leakage issue.

Thanks for the updated patch.  I didn't find anything to complain about.

> I haven't removed equalPartitionDescs here; that seems like material
> for a separate patch (to make it easier to put it back if we need it).

Seems like a good idea.

Btw, does the memory leakage fix in this patch address any of the
pending concerns that were discussed on the "hyrax vs.
RelationBuildPartitionDesc" thread earlier this year[1]?

Thanks,
Amit

[1] https://www.postgresql.org/message-id/flat/3800.1560366716%40sss.pgh.pa.us#092b6b4f6bf75d2f3f90ef6a3b3eab5b



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: error context for vacuum to include block number
Next
From: Yugo Nagata
Date:
Subject: Re: Implementing Incremental View Maintenance