Обсуждение: patch - Report the schema along table name in a referential failure error message
patch - Report the schema along table name in a referential failure error message
От
George Gensure
Дата:
I've put together a small patch to provide a schema name in an fk violation in deference to the todo item "Report the schema along table name in a referential failure error message" The error message only contains the schema if the table name being referenced is non-unique or not present in the search_path. It passes a make check, and I've added a couple of test cases which expect the schema's output in the cases mentioned above. Also, it looks like Rev 1.113 added spaces to the values specified in errdetail for failed FK violations, but the testoutput wasn't updated. I haven't included that in this patch for clarity, but it probably should be corrected. Have at it, -George
Вложения
George Gensure <werkt0@gmail.com> writes: > I've put together a small patch to provide a schema name in an fk > violation in deference to the todo item "Report the schema along table > name in a referential failure error message" This is not the way forward; if it were, we would have done it years ago. Despite the poor wording of the TODO item, nobody is particularly interested in solving this problem one error message at a time. Furthermore, inserting the schema name into the text as you have done it is 100% wrong --- in an example like... table "non_searched_schema.fknsref" violates ... the reader could be excused for thinking that the report is showing an unqualified name that happens to include a dot, because that's what double quotes imply in SQL. And it certainly does not help client-side tools that want to extract the full table name, which is the real subtext behind many of the requests for this. The direction that we really want to move in is to include the table and schema names as well as other elements of the standard "diagnostics area" as separate fields in error reports. That will be a great deal of work unfortunately :-( which is why it hasn't been tackled yet. regards, tom lane
Re: patch - Report the schema along table name in a referential failure error message
От
George Gensure
Дата:
On Sun, Nov 15, 2009 at 11:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > George Gensure <werkt0@gmail.com> writes: >> I've put together a small patch to provide a schema name in an fk >> violation in deference to the todo item "Report the schema along table >> name in a referential failure error message" > > This is not the way forward; if it were, we would have done it years > ago. Despite the poor wording of the TODO item, nobody is particularly > interested in solving this problem one error message at a time. > Furthermore, inserting the schema name into the text as you have done it > is 100% wrong --- in an example like > ... table "non_searched_schema.fknsref" violates ... > the reader could be excused for thinking that the report is showing > an unqualified name that happens to include a dot, because that's > what double quotes imply in SQL. And it certainly does not help > client-side tools that want to extract the full table name, which > is the real subtext behind many of the requests for this. > > The direction that we really want to move in is to include the table and > schema names as well as other elements of the standard "diagnostics > area" as separate fields in error reports. That will be a great deal > of work unfortunately :-( which is why it hasn't been tackled yet. > > regards, tom lane > Fair enough, and I hadn't even considered that dots could be valid chars in table names. I noted your post in the chain attached to this todo request in which you said this is a much bigger problem, but didn't think that you would have left it marked as easy if you thought there should be something done that makes the original error string modification pointless. This begs a bigger question: what's *really* easy or low barrier to entry for very light contributors like myself? - I've got time, I like the product, I need to know what's going to get you a win, I may not be gunning particularly for the feature myself. Its fascinating that this item also included a mention of straw polling in its thread. Thanks, -George
Re: patch - Report the schema along table name in a referential failure error message
От
Andrew Dunstan
Дата:
George Gensure wrote: > This begs a bigger question: what's *really* easy or low barrier to > entry for very light contributors like myself? - I've got time, I like > the product, I need to know what's going to get you a win, I may not > be gunning particularly for the feature myself. The TODO list at <http://wiki.postgresql.org/wiki/Todo> doesn't seem to have a huge number or [E] items. Maybe we need a bit of a brainstorm to come up with a few more. The one I just started talking about (using param names in SQL functions) might not be terribly hard, depending on your coding skills, since it would be making use of the new parser hooks feature that Tom has just done the heavy lifting on. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes: > George Gensure wrote: >> This begs a bigger question: what's *really* easy or low barrier to >> entry for very light contributors like myself? > The TODO list at <http://wiki.postgresql.org/wiki/Todo> doesn't seem to > have a huge number or [E] items. Maybe we need a bit of a brainstorm to > come up with a few more. The real problem with the entry that George picked up on was that it was misdescribed and mislabeled as easy because whoever put it in ignored the fact that there was not a consensus to do a half-baked fix ... this is a problem with a wiki TODO list :-( > The one I just started talking about (using param names in SQL > functions) might not be terribly hard, depending on your coding skills, > since it would be making use of the new parser hooks feature that Tom > has just done the heavy lifting on. It is easy ... as long as you don't move the goalposts by insisting on inventing some nonstandard syntax. I would envision that givencreate function f (x int) you should be able to refer to the parameter as "x" or "f.x" if you need to qualify it. This matches plpgsql practice and won't surprise anybody, and can be implemented with a couple hours' hacking I'd guess. regards, tom lane
Re: patch - Report the schema along table name in a referential failure error message
От
Brendan Jurd
Дата:
2009/11/16 Tom Lane <tgl@sss.pgh.pa.us>: > The real problem with the entry that George picked up on was that it was > misdescribed and mislabeled as easy because whoever put it in ignored > the fact that there was not a consensus to do a half-baked fix ... > this is a problem with a wiki TODO list :-( Wouldn't it be more accurate to say that it's a problem with *any* TODO list? I don't see what the wiki has to do with it. Garbage in, garbage out. A poorly described item will always be trouble regardless of what form it is in. However, I'm not sure how productive the [E]asy marker can really be. Items end up on the TODO generally because a) we couldn't settle on a way forward, or b) nobody was keen to do it right away. There just aren't many genuinely "easy" items in there, easy ones usually get done right away. Cheers, BJ
Brendan Jurd <direvus@gmail.com> writes: > However, I'm not sure how productive the [E]asy marker can really be. > Items end up on the TODO generally because a) we couldn't settle on a > way forward, or b) nobody was keen to do it right away. There just > aren't many genuinely "easy" items in there, easy ones usually get > done right away. Yeah, that is a real problem for new would-be contributors --- there simply isn't that much low-hanging fruit waiting for them, unless they focus on areas that no one else has taken much interest in; and even then there are few really small tasks. regards, tom lane
Re: patch - Report the schema along table name in a referential failure error message
От
Andrew Dunstan
Дата:
Tom Lane wrote: > > Yeah, that is a real problem for new would-be contributors --- there > simply isn't that much low-hanging fruit waiting for them, unless > they focus on areas that no one else has taken much interest in; > and even then there are few really small tasks. > > Then I think we need to start being more creative about ways to ease the path for people who want to get people involved. cheers andrew
On Nov 15, 2009, at 5:14 PM, Andrew Dunstan wrote: > Then I think we need to start being more creative about ways to ease > the path for people who want to get people involved. With that as an inspiration, I'd like to offer a modest proposal: Apprentices. In my case, I would be very exciting about participating more in PG development. I have a reasonable amount of C/C++ experience (20-ish years), and have been a PG admin/client developer since 1998, but I lack enough familiarity with the codebase to do patch review on non- trivial patches, or to launch in and do development on a non-trivial feature. (And, as has been noted, there are essential no non-trivial features needing work.) On the other hand, I'm sure there are those such as myself who are perfectly capable in *assisting* in some way: Reviewing a patch for specific things, writing test cases, working on a subsection of a larger patch. This also is a solution for the intimidating prospect of working on a large patch and being sold, "Um, that's really completely the wrong thing. Sorry." Not every primary contribution or patch reviewer is going to be comfortable working with other people, because of temperament or work style, but I'm sure some are. Might this help? -- -- Christophe Pettus xof@thebuild.com
Re: patch - Report the schema along table name in a referential failure error message
От
George Gensure
Дата:
On Sun, Nov 15, 2009 at 1:43 PM, Andrew Dunstan <andrew@dunslane.net> wrote: > > > George Gensure wrote: >> >> This begs a bigger question: what's *really* easy or low barrier to >> entry for very light contributors like myself? - I've got time, I like >> the product, I need to know what's going to get you a win, I may not >> be gunning particularly for the feature myself. > > > The TODO list at <http://wiki.postgresql.org/wiki/Todo> doesn't seem to have > a huge number or [E] items. Maybe we need a bit of a brainstorm to come up > with a few more. > > The one I just started talking about (using param names in SQL functions) > might not be terribly hard, depending on your coding skills, since it would > be making use of the new parser hooks feature that Tom has just done the > heavy lifting on. > > cheers > > andrew > There's some tricky stuff in here to say the least. Doesn't look like param names are kept anywhere past the parser - gonna have to have it follow through a bunch of functions to reach parse_(fixed|variable)_parameters. The p_post_columnref_hook you alluded to will help once I have the names though, so thanks :) -George
George Gensure <werkt0@gmail.com> writes: > There's some tricky stuff in here to say the least. Doesn't look like > param names are kept anywhere past the parser - gonna have to have it > follow through a bunch of functions to reach > parse_(fixed|variable)_parameters. The p_post_columnref_hook you > alluded to will help once I have the names though, so thanks :) I'm not sure where you're looking, but I would think the place to start is with pulling the parameter names out of the pg_proc tuple in init_sql_fcache. regards, tom lane
Re: patch - Report the schema along table name in a referential failure error message
От
Alvaro Herrera
Дата:
Tom Lane escribió: > George Gensure <werkt0@gmail.com> writes: > > I've put together a small patch to provide a schema name in an fk > > violation in deference to the todo item "Report the schema along table > > name in a referential failure error message" > > This is not the way forward; if it were, we would have done it years > ago. Despite the poor wording of the TODO item, nobody is particularly > interested in solving this problem one error message at a time. FWIW see this thread http://archives.postgresql.org/pgsql-hackers/2009-08/msg00213.php -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.