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

Re: [pgAdmin III] #148: Miscellaneous requests for the query tool

From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: "Dickson S(dot) Guedes" <listas(at)guedesoft(dot)net>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: [pgAdmin III] #148: Miscellaneous requests for the query tool
Date: 2010-04-24 19:45:57
Message-ID: (view raw or whole thread)
Lists: pgadmin-hackers
Le 11/04/2010 09:37, Guillaume Lelarge a écrit :
> Le 21/03/2010 18:53, Dickson S. Guedes a écrit :
>> 2010/3/20 Guillaume Lelarge <guillaume(at)lelarge(dot)info>:
>>> Applies and compiles with no issue.
>> Good!
>>> Anyways there are a few things that I don't like.
>> I'm already wainting for. :-)
>>> When the combobox contains the maximum number of queries, it should
>>> delete the older one and record the new one whereas now it simply
>>> doesn't do anything.
>> Yes, i was in doubt whether I delete the oldest query or not, but your
>> review answers my doubt.
>>> What happens when pgAdmin loads a queries file with more than the
>>> maximum number of queries in it? AFAICT, it loads everything. I think it
>>> shouldn't. It should only load the X last one (X being the maximum
>>> number of queries).
>> I agree.
>>> I don't think the default maximum query size is sane. 100 characters are
>>> really not enough. At least 1024 (much like track_activity_query_size).
>>> By the way, I also don't think we should talk in bytes. It's a number of
>>> characters.
>> Sounds better for me, too.
>>> I think that's all for me. Can you send us an updated patch?
>> Yes, I can.
> Did you find some time to finish this patch?

You won't need to. I changed your patch to mke it commitable. Patch



Attachment: ticket148_v1.patch
Description: text/x-patch (10.0 KB)

In response to


pgadmin-hackers by date

Next:From: pgAdmin TracDate: 2010-04-24 19:46:14
Subject: Re: [pgAdmin III] #145: Output to file
Previous:From: pgAdmin TracDate: 2010-04-24 06:53:00
Subject: Re: [pgAdmin III] #44: Ensure frmEditGrid survives a drop/create of the underlying relation

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