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. -- 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
