On 2018-Jul-11, Amit Langote wrote: > On 2018/07/11 13:12, Alvaro Herrera wrote: > > On 2018-Jul-11, Amit Langote wrote: > > > >> What's the solution here then? Prevent domains as partition key? > > > > Maybe if a domain is used in a partition key somewhere, prevent > > constraints from being added? > > Maybe, but I guess you mean only prevent adding such a constraint > after-the-fact.
Yeah, any domain constraints added before won't be a problem. Another angle on this problem is to verify partition bounds against the domain constraint being added; if they all pass, there's no reason to reject the constraint. But I worry that Tom was using domain constraints as just an example of a more general problem that we can get into. > If a domain has a constraint before creating any partitions based on the > domain, then partition creation command would check that the partition > bound values satisfy those constraints. Of course. > > Another thing worth considering: are you prevented from dropping a > > domain that's used in a partition key? If not, you get an ugly message > > when you later try to drop the table. > > Yeah, I was about to write a message about that. I think we need to teach > RemoveAttributeById, which dependency.c calls when dropping the > referencing domain with cascade option, to abort if the attribute passed > to it belongs to the partition key of the input relation. Actually, here's another problem: why are we letting a column on a domain become partition key, if you'll never be able to create a partition? It seems that for pg11 the right reaction is to check the partition key and reject this case. I'm not sure of this implementation -- I couldn't find any case where we reject the deletion on the function called from doDeletion (and we don't have a preliminary phase on which to check for this, either). Maybe we need a pg_depend entry to prevent this, though it seems a little silly. Maybe we should add a preliminary verification phase in deleteObjectsInList(), where we invoke object-type-specific checks. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
