[HACKERS] Patch - Reference Function Parameters by Name
Attached is a patch to perform parameter reference lookups by name in the body of functions. I'm hesitant to put it in for the commitfest as is, without a couple of questions posed to the group: 1. palloc needs no free? I suppose this is a general knowledge question, but it seemed to be the case after trying to look for deallocation 2. I inserted myself more than I had expected along the road from SQL to columnref_hook, and I'm not sure all of those lookups of parameter names and function name are required. 3. Since it was mentioned in an earlier email that the function name.parameter name syntax was desired, I went ahead and added that, but it required another passthrough as indicated in 2 4. I made a judgement call in terms of resolution: if the columnref_hook for param-by-name resolution is called with a non-null node (meaning a column was already found), we avoid being an ambiguous reference, and prefer the column already found. Passes all tests in make check, and I'll add some tests for this after I get feedback for the above items. Regards, -George param_names.patch Description: Binary data -- 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
[HACKERS] commitfest patch move unavailable
After consulting with some other members of the community, I tried to post my fk error string patch to the current commitfest, but mistakenly posted it to the current commitfest, not the open one. When I tried to correct this by moving the patch to the open 2010-01 commitfest, I could not submit the form to do so because the open commitfest does not contain any topics. Seems like a lot of pain for a casual commit... -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
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
[HACKERS] patch - Report the schema along table name in a referential failure error message
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 fk_schemas.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
