Re: [HACKERS] patch - Report the schema along table name in a referential failure error message
George Gensure wer...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch - Report the schema along table name in a referential failure error message
Tom Lane escribió: George Gensure wer...@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 Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch - Report the schema along table name in a referential failure error message
On Sun, Nov 15, 2009 at 1:43 PM, Andrew Dunstan and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch - Report the schema along table name in a referential failure error message
George Gensure wer...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch - Report the schema along table name in a referential failure error message
On Sun, Nov 15, 2009 at 11:21 AM, Tom Lane t...@sss.pgh.pa.us wrote: George Gensure wer...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch - Report the schema along table name in a referential failure error message
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch - Report the schema along table name in a referential failure error message
Andrew Dunstan and...@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 given create 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch - Report the schema along table name in a referential failure error message
2009/11/16 Tom Lane t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch - Report the schema along table name in a referential failure error message
Brendan Jurd dire...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch - Report the schema along table name in a referential failure error message
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
