Skip site navigation (1) Skip section navigation (2)

Re: Feature Request: SQL parameters

From: Bernhard Neuhauser <bneuhauser(at)real(dot)com>
To: Eric Schwarzenbach <subscriber(at)blackbrook(dot)org>, "pgadmin-support(at)postgresql(dot)org" <pgadmin-support(at)postgresql(dot)org>
Subject: Re: Feature Request: SQL parameters
Date: 2011-03-19 21:39:06
Message-ID: FACFAC06BB4349408E9FD5D9CAAE6F920854861BB3@SEAMBX.corp.real.com (view raw or flat)
Thread:
Lists: 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

In response to

pgadmin-support by date

Next:From: Edgar SepulvedaDate: 2011-03-21 16:05:32
Subject: Re: Execute arbitrary SQL queries does not come up in pgAdmin
Previous:From: Pavel StehuleDate: 2011-03-19 21:29:52
Subject: Re: Feature Request: SQL parameters

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group