Le vendredi 4 décembre 2009 à 10:52:33, Dave Page a écrit : > On Fri, Dec 4, 2009 at 9:41 AM, Guillaume Lelarge > > <[email protected]> wrote: > > Hi, > > > > Someone, on a french PostgreSQL forum, ask me for a statement timeout UI > > in the query tool. Here is what I've done so far: > > > > * add a config in the Query tab of the Options window; > > * add a textbox in the toolbar of the query tool; > > We certainly don't need both. >
I see a use case for having both. If someone uses a lot the statement_timeout option, he'll be annoyed to put it in the text box every time he launches the query tool. You'll tell me that he can have a specific user option (with ALTER USER), and you'll be right. But many of my customers don't have specific user for their own connection (which is a bad habit, but also a difficult one to loose). > > * each query executed will first get the old statement_timeout value, > > set statement_timeout to the text box one (which is initialized with the > > config value), execute the real query, and then get back to the old value > > Why save/reset it? The next query will just change it again anyway, > and there's no way round that. > Because every other query launch by the query tool will use it. For example the one of the GQB (which, AFAIK, uses the same connection). > > I checked the UI on Windows, Mac OS X, and Linux. > > What's wrong with just setting it manually in the script anyway? Nothing, if you don't do this a lot. > There are various parameters people might want to set, that we definitely > don't want to add UI for. I'll concede that statement_timeout is more > likely to be used than most others, but it seems to me that forcing it > to be set with every query is far less flexible than just setting it > as and when required in your script. > I don't have any issues with adding a UI for other parameters (work_mem comes to mind immediately). We can put them all in their own toolbar, so that users can hide it, so that it doesn't cluter the window UI. Anyways I don't see a lot of parameters that would need that treatment. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com -- Sent via pgadmin-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
