Обсуждение: Feature Request: SQL parameters
Some years ago I worked with another DB tool, for another DB that offered support for SQL parameters in a way that was extremely handy. I've missed this feature in pgAdmin ever since. By SQL parameters, I mean the replaceable bits one puts as ? in a prepared statement. When testing / debugging sql from application code, it is a major annoyance to have to constantly find and replace these ?'s. I forget exactly how the feature in the other tool worked...it may have actually detected the ?'s and prompted you for values the moment you tried to execute it. But the important thing was that it allowed you to leave the ?'s in the query, and gave you a place to fill in the parameter values to be used when you execute it. This may not sound like much on the surface, but makes an enormous difference. It: * avoids having to hunt down the ? in a large complex query * keeps your query looking more as it appears in your source code (and you can more easily paste it back in after you've modified it in pgadmin) * keeps you from losing track of where the ?s were before you replaced them * is handier for testing out different values for the parameters.
Le 03/03/2011 00:03, Eric Schwarzenbach a écrit : > Some years ago I worked with another DB tool, for another DB that > offered support for SQL parameters in a way that was extremely handy. > I've missed this feature in pgAdmin ever since. By SQL parameters, I > mean the replaceable bits one puts as ? in a prepared statement. > > When testing / debugging sql from application code, it is a major > annoyance to have to constantly find and replace these ?'s. I forget > exactly how the feature in the other tool worked...it may have actually > detected the ?'s and prompted you for values the moment you tried to > execute it. But the important thing was that it allowed you to leave the > ?'s in the query, and gave you a place to fill in the parameter values > to be used when you execute it. This may not sound like much on the > surface, but makes an enormous difference. It: > > * avoids having to hunt down the ? in a large complex query > * keeps your query looking more as it appears in your source code (and > you can more easily paste it back in after you've modified it in pgadmin) > * keeps you from losing track of where the ?s were before you replaced them > * is handier for testing out different values for the parameters. > I'm not sure I understand what you would like to have. That pgAdmin asks for values anytime it encounters a question mark in a query? -- Guillaumehttp://www.postgresql.frhttp://dalibo.com
On Sat, Mar 5, 2011 at 20:39, Guillaume Lelarge <span dir="ltr"><<a href="mailto:guillaume@lelarge.info">guillaume@lelarge.info</a>></span>wrote:<br /><div class="gmail_quote"><blockquoteclass="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204,204); padding-left: 1ex;"><div id=":1u8">I'm not sure I understand what you would like to have. That pgAdmin asks<br/> for values anytime it encounters a question mark in a query?</div></blockquote></div><br />Yes, and I would reallylike that, too. As well as named parameters and things like $1.<br />Look how fun psql is to use:<br /><br />vik=#\set paramname 5<br /> vik=# select :paramname;<br /> ?column? <br />----------<br /> 5<br />(1 row)<br /><br/>vik=# <br /><br />It would be great if pgAdmin could excute similar queries.<br />
On , Sat, 05 Mar 2011 20:39:53 +0100, Guillaume wrote > Le 03/03/2011 00:03, Eric Schwarzenbach a écrit : > > Some years ago I worked with another DB tool, for another DB that > > offered support for SQL parameters in a way that was extremely handy. > > I've missed this feature in pgAdmin ever since. By SQL parameters, I > > mean the replaceable bits one puts as ? in a prepared statement. > > > > When testing / debugging sql from application code, it is a major > > annoyance to have to constantly find and replace these ?'s. I forget > > exactly how the feature in the other tool worked...it may have actually > > detected the ?'s and prompted you for values the moment you tried to > > execute it. But the important thing was that it allowed you to leave the > > ?'s in the query, and gave you a place to fill in the parameter values > > to be used when you execute it. This may not sound like much on the > > surface, but makes an enormous difference. It: > > > > * avoids having to hunt down the ? in a large complex query > > * keeps your query looking more as it appears in your source code (and > > you can more easily paste it back in after you've modified it in pgadmin) > > * keeps you from losing track of where the ?s were before you replaced them > > * is handier for testing out different values for the parameters. > > > > I'm not sure I understand what you would like to have. That pgAdmin asks > for values anytime it encounters a question mark in a query? Sorry if I was a bit vague. I figured there might be a number of UI approaches to handling this, some of which might be easier or harder given pgadmin facilities, and didn't want to my request to get bogged down in Hows rather than Whats, but maybe they are necessary to convey the idea. I'll sketch out a few ways I can see it working: The main feature I'm looking for is a way to let the user supply a list of values to be used to replace the ?'s when executing the query. Now if pgAdmin could detect the ?'s and prompt the user to use this facility, all the better, but this isn't strictly necessary. The user, knowing he has ?'s in his query could manually open the dialog or panel or whatever for entering parameter values (for the sake of argument I'll suppose it is a panel, the "parameter panel". The important thing is being able to enter the values in some more central location rather than hunting through what may be many lines of SQL. The effect should be that the SQL in the editor pane remains unchanged, with the ?'s in place, but when you execute your query PgAdmin replaces them with the values you have entered in the parameter panel. The How of the interface for entering them is probably important for how easy this is in the use case I have in mind (debugging application code SQL), but may be dependent on the tools the user is using. Perhaps several options could be provided. For my own case, debugging Java in Eclipse., I can generally copy the parameters out of the list in the debugger in the form of a comma separated list. So the ability to simply paste in this list would be ideal for me. I don't know how ideal this would be for other users using other debuggers, but perhaps others will give input here. A small feature that would be really sweet, as part of this, would be is pgAdmin were able to highlight a given ? in the SQL when you select a given parameter in the parameter panel. Eric
2011/3/19 Eric Schwarzenbach <subscriber@blackbrook.org>: > On , Sat, 05 Mar 2011 20:39:53 +0100, Guillaume wrote >> >> Le 03/03/2011 00:03, Eric Schwarzenbach a écrit : >> > Some years ago I worked with another DB tool, for another DB that >> > offered support for SQL parameters in a way that was extremely handy. >> > I've missed this feature in pgAdmin ever since. By SQL parameters, I >> > mean the replaceable bits one puts as ? in a prepared statement. >> > >> > When testing / debugging sql from application code, it is a major >> > annoyance to have to constantly find and replace these ?'s. I forget >> > exactly how the feature in the other tool worked...it may have actually >> > detected the ?'s and prompted you for values the moment you tried to >> > execute it. But the important thing was that it allowed you to leave >> > the >> > ?'s in the query, and gave you a place to fill in the parameter values >> > to be used when you execute it. This may not sound like much on the >> > surface, but makes an enormous difference. It: >> > >> > * avoids having to hunt down the ? in a large complex query >> > * keeps your query looking more as it appears in your source code (and >> > you can more easily paste it back in after you've modified it in >> > pgadmin) >> > * keeps you from losing track of where the ?s were before you replaced >> > them >> > * is handier for testing out different values for the parameters. >> > >> >> I'm not sure I understand what you would like to have. That pgAdmin asks >> for values anytime it encounters a question mark in a query? > > Sorry if I was a bit vague. I figured there might be a number of UI > approaches to handling this, some of which might be easier or harder given > pgadmin facilities, and didn't want to my request to get bogged down in Hows > rather than Whats, but maybe they are necessary to convey the idea. > > I'll sketch out a few ways I can see it working: > > The main feature I'm looking for is a way to let the user supply a list of > values to be used to replace the ?'s when executing the query. Now if > pgAdmin could detect the ?'s and prompt the user to use this facility, all > the better, but this isn't strictly necessary. The user, knowing he has ?'s > in his query could manually open the dialog or panel or whatever for > entering parameter values (for the sake of argument I'll suppose it is a > panel, the "parameter panel". The important thing is being able to enter the > values in some more central location rather than hunting through what may be > many lines of SQL. The effect should be that the SQL in the editor pane > remains unchanged, with the ?'s in place, but when you execute your query > PgAdmin replaces them with the values you have entered in the parameter > panel. > > The How of the interface for entering them is probably important for how > easy this is in the use case I have in mind (debugging application code > SQL), but may be dependent on the tools the user is using. Perhaps several > options could be provided. For my own case, debugging Java in Eclipse., I > can generally copy the parameters out of the list in the debugger in the > form of a comma separated list. So the ability to simply paste in this list > would be ideal for me. I don't know how ideal this would be for other users > using other debuggers, but perhaps others will give input here. > > A small feature that would be really sweet, as part of this, would be is > pgAdmin were able to highlight a given ? in the SQL when you select a given > parameter in the parameter panel. > using $n notation can be more faster and simpler for implementation - and practic, because programmer can check a prepared statements or parametrised queries in pgAdmin. Regards Pavel Stehule > Eric > > -- > Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgadmin-support >
>> > > using $n notation can be more faster and simpler for implementation - > and practic, because programmer can check a prepared statements or > parametrised queries in pgAdmin. > and there is a parser's hook that support searching a parameters in query. Regards Pavel Stehule
On 3/19/2011 12:21 PM, Pavel Stehule wrote: > 2011/3/19 Eric Schwarzenbach<subscriber@blackbrook.org>: >> On , Sat, 05 Mar 2011 20:39:53 +0100, Guillaume wrote >>> Le 03/03/2011 00:03, Eric Schwarzenbach a écrit : >>>> Some years ago I worked with another DB tool, for another DB that >>>> offered support for SQL parameters in a way that was extremely handy. >>>> I've missed this feature in pgAdmin ever since. By SQL parameters, I >>>> mean the replaceable bits one puts as ? in a prepared statement. >>>> >>>> When testing / debugging sql from application code, it is a major >>>> annoyance to have to constantly find and replace these ?'s. I forget >>>> exactly how the feature in the other tool worked...it may have actually >>>> detected the ?'s and prompted you for values the moment you tried to >>>> execute it. But the important thing was that it allowed you to leave >>>> the >>>> ?'s in the query, and gave you a place to fill in the parameter values >>>> to be used when you execute it. This may not sound like much on the >>>> surface, but makes an enormous difference. It: >>>> >>>> * avoids having to hunt down the ? in a large complex query >>>> * keeps your query looking more as it appears in your source code (and >>>> you can more easily paste it back in after you've modified it in >>>> pgadmin) >>>> * keeps you from losing track of where the ?s were before you replaced >>>> them >>>> * is handier for testing out different values for the parameters. >>>> >>> I'm not sure I understand what you would like to have. That pgAdmin asks >>> for values anytime it encounters a question mark in a query? >> Sorry if I was a bit vague. I figured there might be a number of UI >> approaches to handling this, some of which might be easier or harder given >> pgadmin facilities, and didn't want to my request to get bogged down in Hows >> rather than Whats, but maybe they are necessary to convey the idea. >> >> I'll sketch out a few ways I can see it working: >> >> The main feature I'm looking for is a way to let the user supply a list of >> values to be used to replace the ?'s when executing the query. Now if >> pgAdmin could detect the ?'s and prompt the user to use this facility, all >> the better, but this isn't strictly necessary. The user, knowing he has ?'s >> in his query could manually open the dialog or panel or whatever for >> entering parameter values (for the sake of argument I'll suppose it is a >> panel, the "parameter panel". The important thing is being able to enter the >> values in some more central location rather than hunting through what may be >> many lines of SQL. The effect should be that the SQL in the editor pane >> remains unchanged, with the ?'s in place, but when you execute your query >> PgAdmin replaces them with the values you have entered in the parameter >> panel. >> >> The How of the interface for entering them is probably important for how >> easy this is in the use case I have in mind (debugging application code >> SQL), but may be dependent on the tools the user is using. Perhaps several >> options could be provided. For my own case, debugging Java in Eclipse., I >> can generally copy the parameters out of the list in the debugger in the >> form of a comma separated list. So the ability to simply paste in this list >> would be ideal for me. I don't know how ideal this would be for other users >> using other debuggers, but perhaps others will give input here. >> >> A small feature that would be really sweet, as part of this, would be is >> pgAdmin were able to highlight a given ? in the SQL when you select a given >> parameter in the parameter panel. >> > using $n notation can be more faster and simpler for implementation - > and practic, because programmer can check a prepared statements or > parametrised queries in pgAdmin. > > Regards > > Pavel Stehule > I don't believe this $n notation is supported in JDBC prepared statements. Eric
2011/3/19 Eric Schwarzenbach <subscriber@blackbrook.org>: > On 3/19/2011 12:21 PM, Pavel Stehule wrote: >> >> 2011/3/19 Eric Schwarzenbach<subscriber@blackbrook.org>: >>> >>> On , Sat, 05 Mar 2011 20:39:53 +0100, Guillaume wrote >>>> >>>> Le 03/03/2011 00:03, Eric Schwarzenbach a écrit : >>>>> >>>>> Some years ago I worked with another DB tool, for another DB that >>>>> offered support for SQL parameters in a way that was extremely handy. >>>>> I've missed this feature in pgAdmin ever since. By SQL parameters, I >>>>> mean the replaceable bits one puts as ? in a prepared statement. >>>>> >>>>> When testing / debugging sql from application code, it is a major >>>>> annoyance to have to constantly find and replace these ?'s. I forget >>>>> exactly how the feature in the other tool worked...it may have >>>>> actually >>>>> detected the ?'s and prompted you for values the moment you tried to >>>>> execute it. But the important thing was that it allowed you to leave >>>>> the >>>>> ?'s in the query, and gave you a place to fill in the parameter values >>>>> to be used when you execute it. This may not sound like much on the >>>>> surface, but makes an enormous difference. It: >>>>> >>>>> * avoids having to hunt down the ? in a large complex query >>>>> * keeps your query looking more as it appears in your source code (and >>>>> you can more easily paste it back in after you've modified it in >>>>> pgadmin) >>>>> * keeps you from losing track of where the ?s were before you replaced >>>>> them >>>>> * is handier for testing out different values for the parameters. >>>>> >>>> I'm not sure I understand what you would like to have. That pgAdmin asks >>>> for values anytime it encounters a question mark in a query? >>> >>> Sorry if I was a bit vague. I figured there might be a number of UI >>> approaches to handling this, some of which might be easier or harder >>> given >>> pgadmin facilities, and didn't want to my request to get bogged down in >>> Hows >>> rather than Whats, but maybe they are necessary to convey the idea. >>> >>> I'll sketch out a few ways I can see it working: >>> >>> The main feature I'm looking for is a way to let the user supply a list >>> of >>> values to be used to replace the ?'s when executing the query. Now if >>> pgAdmin could detect the ?'s and prompt the user to use this facility, >>> all >>> the better, but this isn't strictly necessary. The user, knowing he has >>> ?'s >>> in his query could manually open the dialog or panel or whatever for >>> entering parameter values (for the sake of argument I'll suppose it is a >>> panel, the "parameter panel". The important thing is being able to enter >>> the >>> values in some more central location rather than hunting through what may >>> be >>> many lines of SQL. The effect should be that the SQL in the editor pane >>> remains unchanged, with the ?'s in place, but when you execute your query >>> PgAdmin replaces them with the values you have entered in the parameter >>> panel. >>> >>> The How of the interface for entering them is probably important for how >>> easy this is in the use case I have in mind (debugging application code >>> SQL), but may be dependent on the tools the user is using. Perhaps >>> several >>> options could be provided. For my own case, debugging Java in Eclipse., I >>> can generally copy the parameters out of the list in the debugger in the >>> form of a comma separated list. So the ability to simply paste in this >>> list >>> would be ideal for me. I don't know how ideal this would be for other >>> users >>> using other debuggers, but perhaps others will give input here. >>> >>> A small feature that would be really sweet, as part of this, would be is >>> pgAdmin were able to highlight a given ? in the SQL when you select a >>> given >>> parameter in the parameter panel. >>> >> using $n notation can be more faster and simpler for implementation - >> and practic, because programmer can check a prepared statements or >> parametrised queries in pgAdmin. >> >> Regards >> >> Pavel Stehule >> > I don't believe this $n notation is supported in JDBC prepared statements. There isn't only JDBC - libpq support it. Pavel > > Eric > > -- > Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgadmin-support >
On 3/19/2011 1:52 PM, Pavel Stehule wrote: > 2011/3/19 Eric Schwarzenbach<subscriber@blackbrook.org>: >> On 3/19/2011 12:21 PM, Pavel Stehule wrote: >>> 2011/3/19 Eric Schwarzenbach<subscriber@blackbrook.org>: >>>> On , Sat, 05 Mar 2011 20:39:53 +0100, Guillaume wrote >>>>> Le 03/03/2011 00:03, Eric Schwarzenbach a écrit : >>>>>> Some years ago I worked with another DB tool, for another DB that >>>>>> offered support for SQL parameters in a way that was extremely handy. >>>>>> I've missed this feature in pgAdmin ever since. By SQL parameters, I >>>>>> mean the replaceable bits one puts as ? in a prepared statement. >>>>>> >>>>>> When testing / debugging sql from application code, it is a major >>>>>> annoyance to have to constantly find and replace these ?'s. I forget >>>>>> exactly how the feature in the other tool worked...it may have >>>>>> actually >>>>>> detected the ?'s and prompted you for values the moment you tried to >>>>>> execute it. But the important thing was that it allowed you to leave >>>>>> the >>>>>> ?'s in the query, and gave you a place to fill in the parameter values >>>>>> to be used when you execute it. This may not sound like much on the >>>>>> surface, but makes an enormous difference. It: >>>>>> >>>>>> * avoids having to hunt down the ? in a large complex query >>>>>> * keeps your query looking more as it appears in your source code (and >>>>>> you can more easily paste it back in after you've modified it in >>>>>> pgadmin) >>>>>> * keeps you from losing track of where the ?s were before you replaced >>>>>> them >>>>>> * is handier for testing out different values for the parameters. >>>>>> >>>>> I'm not sure I understand what you would like to have. That pgAdmin asks >>>>> for values anytime it encounters a question mark in a query? >>>> Sorry if I was a bit vague. I figured there might be a number of UI >>>> approaches to handling this, some of which might be easier or harder >>>> given >>>> pgadmin facilities, and didn't want to my request to get bogged down in >>>> Hows >>>> rather than Whats, but maybe they are necessary to convey the idea. >>>> >>>> I'll sketch out a few ways I can see it working: >>>> >>>> The main feature I'm looking for is a way to let the user supply a list >>>> of >>>> values to be used to replace the ?'s when executing the query. Now if >>>> pgAdmin could detect the ?'s and prompt the user to use this facility, >>>> all >>>> the better, but this isn't strictly necessary. The user, knowing he has >>>> ?'s >>>> in his query could manually open the dialog or panel or whatever for >>>> entering parameter values (for the sake of argument I'll suppose it is a >>>> panel, the "parameter panel". The important thing is being able to enter >>>> the >>>> values in some more central location rather than hunting through what may >>>> be >>>> many lines of SQL. The effect should be that the SQL in the editor pane >>>> remains unchanged, with the ?'s in place, but when you execute your query >>>> PgAdmin replaces them with the values you have entered in the parameter >>>> panel. >>>> >>>> The How of the interface for entering them is probably important for how >>>> easy this is in the use case I have in mind (debugging application code >>>> SQL), but may be dependent on the tools the user is using. Perhaps >>>> several >>>> options could be provided. For my own case, debugging Java in Eclipse., I >>>> can generally copy the parameters out of the list in the debugger in the >>>> form of a comma separated list. So the ability to simply paste in this >>>> list >>>> would be ideal for me. I don't know how ideal this would be for other >>>> users >>>> using other debuggers, but perhaps others will give input here. >>>> >>>> A small feature that would be really sweet, as part of this, would be is >>>> pgAdmin were able to highlight a given ? in the SQL when you select a >>>> given >>>> parameter in the parameter panel. >>>> >>> using $n notation can be more faster and simpler for implementation - >>> and practic, because programmer can check a prepared statements or >>> parametrised queries in pgAdmin. >>> >>> Regards >>> >>> Pavel Stehule >>> >> I don't believe this $n notation is supported in JDBC prepared statements. > There isn't only JDBC - libpq support it. > > Pavel > Ok, but the use-case I'm talking about is debugging applications using SQL, in my case an application using JDBC. Maybe I'm misunderstanding the point of your post. I'm taking it as suggesting I switch to using $n notation. This isn't an option. Perhaps you are requesting that if the feature I requested be implemented it support $n notation also? If so, this sounds like a good idea. It should support all common SQL parameters notations. Eric
2011/3/19 Eric Schwarzenbach <subscriber@blackbrook.org>: > On 3/19/2011 1:52 PM, Pavel Stehule wrote: >> >> 2011/3/19 Eric Schwarzenbach<subscriber@blackbrook.org>: >>> >>> On 3/19/2011 12:21 PM, Pavel Stehule wrote: >>>> >>>> 2011/3/19 Eric Schwarzenbach<subscriber@blackbrook.org>: >>>>> >>>>> On , Sat, 05 Mar 2011 20:39:53 +0100, Guillaume wrote >>>>>> >>>>>> Le 03/03/2011 00:03, Eric Schwarzenbach a écrit : >>>>>>> >>>>>>> Some years ago I worked with another DB tool, for another DB that >>>>>>> offered support for SQL parameters in a way that was extremely >>>>>>> handy. >>>>>>> I've missed this feature in pgAdmin ever since. By SQL parameters, I >>>>>>> mean the replaceable bits one puts as ? in a prepared statement. >>>>>>> >>>>>>> When testing / debugging sql from application code, it is a major >>>>>>> annoyance to have to constantly find and replace these ?'s. I forget >>>>>>> exactly how the feature in the other tool worked...it may have >>>>>>> actually >>>>>>> detected the ?'s and prompted you for values the moment you tried to >>>>>>> execute it. But the important thing was that it allowed you to leave >>>>>>> the >>>>>>> ?'s in the query, and gave you a place to fill in the parameter >>>>>>> values >>>>>>> to be used when you execute it. This may not sound like much on the >>>>>>> surface, but makes an enormous difference. It: >>>>>>> >>>>>>> * avoids having to hunt down the ? in a large complex query >>>>>>> * keeps your query looking more as it appears in your source code >>>>>>> (and >>>>>>> you can more easily paste it back in after you've modified it in >>>>>>> pgadmin) >>>>>>> * keeps you from losing track of where the ?s were before you >>>>>>> replaced >>>>>>> them >>>>>>> * is handier for testing out different values for the parameters. >>>>>>> >>>>>> I'm not sure I understand what you would like to have. That pgAdmin >>>>>> asks >>>>>> for values anytime it encounters a question mark in a query? >>>>> >>>>> Sorry if I was a bit vague. I figured there might be a number of UI >>>>> approaches to handling this, some of which might be easier or harder >>>>> given >>>>> pgadmin facilities, and didn't want to my request to get bogged down in >>>>> Hows >>>>> rather than Whats, but maybe they are necessary to convey the idea. >>>>> >>>>> I'll sketch out a few ways I can see it working: >>>>> >>>>> The main feature I'm looking for is a way to let the user supply a list >>>>> of >>>>> values to be used to replace the ?'s when executing the query. Now if >>>>> pgAdmin could detect the ?'s and prompt the user to use this facility, >>>>> all >>>>> the better, but this isn't strictly necessary. The user, knowing he has >>>>> ?'s >>>>> in his query could manually open the dialog or panel or whatever for >>>>> entering parameter values (for the sake of argument I'll suppose it is >>>>> a >>>>> panel, the "parameter panel". The important thing is being able to >>>>> enter >>>>> the >>>>> values in some more central location rather than hunting through what >>>>> may >>>>> be >>>>> many lines of SQL. The effect should be that the SQL in the editor pane >>>>> remains unchanged, with the ?'s in place, but when you execute your >>>>> query >>>>> PgAdmin replaces them with the values you have entered in the parameter >>>>> panel. >>>>> >>>>> The How of the interface for entering them is probably important for >>>>> how >>>>> easy this is in the use case I have in mind (debugging application code >>>>> SQL), but may be dependent on the tools the user is using. Perhaps >>>>> several >>>>> options could be provided. For my own case, debugging Java in Eclipse., >>>>> I >>>>> can generally copy the parameters out of the list in the debugger in >>>>> the >>>>> form of a comma separated list. So the ability to simply paste in this >>>>> list >>>>> would be ideal for me. I don't know how ideal this would be for other >>>>> users >>>>> using other debuggers, but perhaps others will give input here. >>>>> >>>>> A small feature that would be really sweet, as part of this, would be >>>>> is >>>>> pgAdmin were able to highlight a given ? in the SQL when you select a >>>>> given >>>>> parameter in the parameter panel. >>>>> >>>> using $n notation can be more faster and simpler for implementation - >>>> and practic, because programmer can check a prepared statements or >>>> parametrised queries in pgAdmin. >>>> >>>> Regards >>>> >>>> Pavel Stehule >>>> >>> I don't believe this $n notation is supported in JDBC prepared >>> statements. >> >> There isn't only JDBC - libpq support it. >> >> Pavel >> > Ok, but the use-case I'm talking about is debugging applications using SQL, > in my case an application using JDBC. Maybe I'm misunderstanding the point > of your post. I'm taking it as suggesting I switch to using $n notation. > This isn't an option. > > Perhaps you are requesting that if the feature I requested be implemented it > support $n notation also? If so, this sounds like a good idea. It should > support all common SQL parameters notations. Probably you can replace $n by ? and back. The advantage of $n is support by internal SQL parser. Pavel > > Eric > > -- > Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgadmin-support >
Hi, > Ok, but the use-case I'm talking about is debugging applications using > SQL, in my case an application using JDBC. Maybe I'm misunderstanding > the point of your post. I'm taking it as suggesting I switch to using $n > notation. This isn't an option. If you are using hibernate (which is not to uncommon in javas world), it's possible to bind variables in native queries using ":bindingname". Spring itself is also using the an identical named parameter binding mechanic. (You need to use Spring JDBC Templates). Additionally I know that toad for oracle uses named parameters like that. That’s somehow funny, because oracle itself is not capable of this syntax (at least not the version I use). But I still like it, because you only need to add the ":" in front of the already available parameter names for debug purpose. I am not sure if this helps, because I don’t know how this mechanics could fit into the PG world. But it highlights one simple aspect: Several independent dev teams tried to bind parameters per name, because often it's most important to create a bug free application in time. Regards, Bernhard