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

From Tom Lane
Subject Re: unsupportable composite type partition keys
Date
Msg-id 26572.1577113220@sss.pgh.pa.us
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  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers
BTW, I forgot to mention: while I think the patch to forbid pseudotypes
by using CheckAttributeType() can be back-patched, I'm leaning towards
not back-patching the other patch.  The situation where we get into
infinite recursion seems not very likely in practice, and it's not
going to cause any crash or data loss, so I think we can just say
"sorry that's not supported before v13".  The patch as I'm proposing
it seems rather invasive for a back-branch fix.  Also, changing
RelationGetPartitionKey/Desc from macros to functions is at least a
weak ABI break.  If there are extensions calling either, they might
still work without a recompile --- but if they have code paths that
are the first thing to touch either field since a relcache flush,
they'd crash.

            regards, tom lane



pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: reduce size of fmgr_builtins array
Next
From: Amit Langote
Date:
Subject: Re: unsupportable composite type partition keys