2012/12/29 Peter Geoghegan <pe...@2ndquadrant.com>: > On 29 December 2012 17:43, Stephen Frost <sfr...@snowman.net> wrote: >> I'd like to see more options for what is logged, as I've mentioned in >> the past, and I think all of these would be good candidates for logging >> in some circumstances. The insistence on having one CSV format to rule >> them all and which doesn't change (except that we've been regularly >> changing it across major releases anyway..) doesn't strike me as the >> right approach. > > Yeah, you're probably right about that. I'm just not sure where it > leaves this patch. > >> It's not entirely clear to me what distinction you're making here or if >> we're simply in agreement about what the necessary fields are. > > I think we might be in agreement. > >> Having the schema name, table name, column name and constraint name >> seems like it's sufficient to fully qualify a specific constraint..? > > Not necessarily, strictly speaking. It's my position that we should > not care about the theoretical edge-cases that this presents. For > example, I don't have any sympathy for the idea that we need to fully > qualify that we're talking about a constraint in a particular schema, > in case there are two distinct constraints in different schemas *that > have the same name but don't do exactly the same thing anyway*. In > cases where there are two distinct constraints with the same name in > the same code path, it seems very likely that the custom error message > to be displayed (or whatever) should not need to differ for each (this > could come up if you were using schemas for multi-tenancy, for > example, and each schema contained the same objects). > > So, in my latest revision of the patch, the only thing that isn't > fully-qualified is constraint_name (because routine_name and so on are > no longer included). It just seems unnecessary, given that only > ERRCODE_CHECK_VIOLATION errors will lack a schema name and table name > (and even then, only sometimes). Pavel originally included a > constraint_schema field, because he figured that the way constraints > are catalogued necessitated such a field.
Design of constraints is little bit different between ANSI SQL and PostgreSQL. And then some fields proposed by standard has no sense in pg - TRIGGER_SCHEMA and probably CONSTRAINT_SCHEMA. Ours constraints are related to some relation - everywhere. You cannot create constraint without relation - so everywhere where CONSTRAINT_NAME is not empty, then TABLE_NAME and TABLE_SCHEMA should be defined or CONSTRAINT_NAME should be unique in database. In my first patch used for these field some expected generated value, but I agree, so it is not necessary and better to drop it, although it can help with readability of some queries. Regards Pavel > > -- > Peter Geoghegan http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
