Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Oct 12, 2018 at 12:39 PM Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
>> I just realized that the current code to assign constraint names to
>> partitions is going against the SQL standard's idea that constraint
>> names must be unique within a schema. When a partition is created, the
>> foreign key gets exactly the same name as the constraint in the parent
>> table.
> I guess I don't see the point in trying to do something about this in
> the partition case but not any other case. The standard may have a
> rule here, but if we don't follow it in general, what benefit do we
> get out of trying to sorta follow it in the specific case of
> partitions with inherited foreign keys? There's probably quite a bit
> of work to do here to fix this properly - I seem to recall some
> previous discussion where it didn't seem simple even to ensure that
> constraint names were unique within a relation in certain corner
> cases.
We moved the goalposts on that recently, see 17b7c302b. Possibly you
are recalling the discussion that led up to that.
> At any rate, -1 from me for inserting a fix like this between rc1 and final.
I agree that this is no time to be messing with it, but I support the
general concept of not intentionally violating the SQL spec for
automatically-chosen constraint names. We get complaints regularly about
the information_schema being inadequate for displaying constraints, and
our only defense against that is "don't violate the SQL spec, and you'll
be fine using the SQL spec's views". That defense falls down if the
system ever automatically chooses duplicate constraint names.
I'm not sure that this would be a good thing to change in a point release,
either :-(. We might have to just delay the fix to v12.
regards, tom lane
