>It would be nice if the following could be configurable:
> * The place where connections and options are stored
> Reason: There are users without roaming profiles, so that
> information cannot be preserved in the registry. An option
> that allows saving these information in some file/directory
> in the home directory (like in the Unix version) would
I don't think we will do something like that. We'll stick to the usual
platform's behaviour, which of course is storing that stuff in the
registry. But it might work to create a pgadmin ini file in the run
directory, you'd have to try and find out.
> * Stopping in case of an SQL error in an SQL window
> Reason: Sometimes you have "drop" statement which yield an
> error if the object does not exist. The following statements
> won't get executed if one fails. It would come in handy if
> stopping in case of an SQL error was avoidable.
The pgsql backend will stop executing the batch. We can't avoid that.
>Some other idea also has to do with the SQL window. Have a look
>at TOra (http://www.globecomm.se/tora). There you can execute the
>statement where the cursor is in, all statements of the SQL window
>or step through the statements one by one. This feature would
>greatly enhance pgAdmin3.
You can mark a statement (or a part of it) and execute it separately. We
don't parse the text or make any assumptions what you might mean to execute.
In response to
pgadmin-hackers by date
|Next:||From: cvs||Date: 2004-05-23 10:20:12|
|Subject: CVS Commit by andreas: urdu|
|Previous:||From: blacknoz||Date: 2004-05-19 12:15:14|
|Subject: debian packages daily builds out of order|