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

Re: Feature Request for Debugging SQL in PGAdmin3 when SQL contains variables

From: "Dan Shoubridge" <dan(dot)shoubridge(at)autovhc(dot)co(dot)uk>
To: "'Guillaume Lelarge'" <guillaume(at)lelarge(dot)info>
Cc: <pgadmin-support(at)postgresql(dot)org>
Subject: Re: Feature Request for Debugging SQL in PGAdmin3 when SQL contains variables
Date: 2010-11-17 09:40:27
Message-ID: 001b01cb863b$7872c110$69584330$ (view raw, whole thread or download thread mbox)
Lists: pgadmin-support
>Le 16/11/2010 23:26, Guillaume Lelarge a écrit :
>> Le 16/11/2010 14:01, Dan Shoubridge a écrit :
>>>>>> Originally from SQL Server background, there is one feature that I 
>>>>>> am missing and would save developers hours of time.
>>>>>> In SQL Server I could copy sql code out of an application and 
>>>>>> paste it into SSMS, declare & assign vars that exist in the sql 
>>>>>> and run - great debugging scenario.
>>>>>> e.g. (please note I am rusty and syntax may be incorrect)
>>>>>> declare @x as varchar(10)
>>>>>> set @x = 'abc'
>>>>>> select * from sometable where somefield = @x
>>>>>> It would be amazing if simular functionality could be built into 
>>>>>> in
>>>>>> pgadmin3 (NpgSQL uses : instead of @) where I can just drop my sql 
>>>>>> (params & all) into the query window.
>>>>>> I realise you can create pgscript, but it doesn't achieve the
>>>>>> Currently I have a peice of sql someone has written that has 3 
>>>>>> unique varibles in it which are used around 7 times each...
>>>>> Le 16/11/2010 13:34, Guillaume Lelarge a écrit :
>>>>> And? I don't see why pgscript can't do that. The example you give 
>>>>> is
>>> certainly doable with pgscript.
>>>>> Just for the record, the above script looks like this in pgscript:
>>>>> declare @x;
>>>>> set @x = 'abc';
>>>>> select * from sometable where somefield = '@x';
>>>>> And it works.
>>> 16/11/2010 13:00, Dan Shoubridge:
>>> (Apologies for messing up my reply, I've not used mailing lists 
>>> before and they never get formatted correctly/
>>> Ok, I tried it - I think I must have missed of the quotes in my 
>>> version, but that still defeats the point - It's easy to replace @ 
>>> with :, but having to put quotes around all the vars makes it less 
>>> efficient. Is there anything that can be done about this?
>> I don't think this is something we want to do. Problem is that 
>> variables are not strictly typed, so there is nothing that could tell 
>> pgscript if it should add simple quotes (simple quotes for text, but 
>> not for integer for example).

Ok, I understand and it’s a shame the vars aren’t strong typed. It's little
things like that that make me want SQL Server back. It doesn't seem like a
big thing to some people, but for a lot of developers the amount of work
added by this when debugging sql adds up over time. 

>>> And I don't get any output in the 'Data Output tab' - this is the 
>>> most important bit. - I can copy and paste the result that I can then 
>>> run, after I've fiddled with the script a bit, but it isn't seamless. 
>>> - Just a request as I think others would find it useful too?
> Yeah, that's quite surprising. I would be useful but quite hard to do.

It's not a case of just capturing the output message and running that? :(

> I think I'll add a ticket on this.

> Ticket added.

I think when I asked this question on stack overflow there was a problem?
But since upgrading pgAdmin it seems to work now. :) Thanks for your help.


Sent via pgadmin-support mailing list (pgadmin-support(at)postgresql(dot)org) To
make changes to your subscription:

In response to


pgadmin-support by date

Next:From: Dave PageDate: 2010-11-17 09:49:56
Subject: Re: Feature Request for Debugging SQL in PGAdmin3 when SQL contains variables
Previous:From: Guillaume LelargeDate: 2010-11-16 22:47:07
Subject: Re: It is possible to add an option to save files without UTF-8 BOM sequence

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