Thread: proposal for configurable behaviour

proposal for configurable behaviour

From
bibjah@bg.bib.de
Date:
Hello!

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
    help.

  * 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.

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.

Sincerely,

Holger
--
Holger Jakobs, Bildungszentrum b.i.b. e. V., Bergisch Gladbach
Fon (+49-22 02) 95 27-3 13  eMail bibjah@bg.bib.de


Re: proposal for configurable behaviour

From
Andreas Pflug
Date:
bibjah@bg.bib.de wrote:

>Hello!
>
>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
>    help.
>
>
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.

Regards,
Andreas