On 4/30/24 09:24, Robert Haas wrote:
> Peter, could you have a look at
> http://postgr.es/m/47550967-260b-4180-9791-b224859fe63e@illuminatedcomputing.com
> and express an opinion about whether each of those proposals are (a)
> good or bad ideas and (b) whether they need to be fixed for the
> current release?
Here are the same patches but rebased. I've added a fourth which is my progress on adding the CHECK
constraint. I don't really consider it finished though, because it has these problems:
- The CHECK constraint should be marked as an internal dependency of the PK, so that you can't drop
it, and it gets dropped when you drop the PK. I don't see a good way to tie the two together though,
so I'd appreciate any advice there. They are separate AlterTableCmds, so how do I get the
ObjectAddress of both constraints at the same time? I wanted to store the PK's ObjectAddress on the
Constraint node, but since ObjectAddress isn't a Node it doesn't work.
- The CHECK constraint should maybe be hidden when you say `\d foo`? Or maybe not, but that's what
we do with FK triggers.
- When you create partitions you get a warning about the constraint already existing, because it
gets created via the PK and then also the partitioning code tries to copy it. Solving the first
issue here should solve this nicely though.
Alternately we could just fix the GROUP BY functional dependency code to only accept b-tree indexes.
But I think the CHECK constraint approach is a better solution.
Thanks,
--
Paul ~{:-)
pj@illuminatedcomputing.com