2012/12/30 Stephen Frost <sfr...@snowman.net>: > * Peter Geoghegan (pe...@2ndquadrant.com) wrote: >> On 30 December 2012 03:32, Stephen Frost <sfr...@snowman.net> wrote: >> > Err. I intended to say "I really don't think what I sketched out, or >> > something similar, would be that unlikely to happen", or something along >> > those lines. Apologies for the confusion. >> >> Almost anything can be misused. > > I agree, almost anything can be. The 'misuse' in this case, however, is > in expecting the information returned to be useful in a deterministic > and consistent manner, as it's being returned in a programmatic fashion. > >> If you're going to insist that I hack a bunch of mechanism into this >> patch so that the user can unambiguously identify each constraint >> object, I'll do that. > > This is the part that I'm having trouble wrapping my head around- what's > the additional complexity here? If we have the OID of the constraint, > we should be able to unambiguoulsy return information which allows a > user to get back to that specific constraint and OID. > >> However, that's more code, and more complexity, >> that will have to be documented, for just next to no practical benefit >> that I can see. > > I've certainly seen cases where constraints are duplicated by name > across schemas. I would imagine it could happen across tables in the > same schema also. I just don't like this notion of returning something > ambiguous to the user and worry that they'd accept it as deterministic > and dependable, regardless of the documentation. There's a certain > amount of "read the docs, but also look at what information you really > get back", which I think is, in general, a good thing, but it does mean > individuals might come to believe that they can depend on the constraint > name being unique in all cases. > > As a side-note, I've recently run into more cases than I care to think > about where the 63-character limit on constraint names has been a > problem- because we're trying to ensure that we create an unambiguous > constraint name, and that's *with* various name shortening techniques > being used. The discussion about having longer values possible for the > 'name' data type was on a different thread and should probably stay > there, but I bring it up because it has some impact on the possibility > of name collisions which is relevent to this discussion.
so - cannot be a solution define CONSTRAINT_TABLE field - constaint names in table are unique. sure there is a problem with long names, but I am thinking so it has solution - when constraint has no name, then we can try to generate name, and when this name is longer than 63 chars, then CREATE STATEMENT fails and users should be define name manually - this feature should be disabled by guc due compatibility issues. Regards Pavel > > Thanks, > > Stephen -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
