Am Samstag, 30. Juli 2005 16:39 schrieb Magnus Hagander:
* Added guc option disable_remote_admin, that disables any write
operations (write, unlink, rename) even for the superuser.
I think it would be better to avoid double negatives, so the option might be
better named enable_remote_admin
Am Montag, 1. August 2005 16:08 schrieb Bruce Momjian:
Would this not work in the context of the general user-specific ALTER
USER ... SET something = something?
No because it isn't a GUC variable, it is per-user/db value.
GUC supports per-user/per-db values.
--
Peter Eisentraut
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Montag, 1. August 2005 16:08 schrieb Bruce Momjian:
Would this not work in the context of the general user-specific ALTER
USER ... SET something = something?
No because it isn't a GUC variable, it is per-user/db value.
GUC supports
Peter Eisentraut wrote:
GUC supports per-user/per-db values.
We already had discussion here about GUC for this and we agreed that
catalog change is better than new GUC variable in this case.
--
Regards
Petr Jelinek (PJMODOS)
---(end of
This was motivated by the SELECT INTO EXACT discussion at
http://archives.postgresql.org/pgsql-patches/2005-07/msg00559.php.
The idea is to allow a PL/pgSQL exception to not automatically rollback
the work done by the current block. The benefit is that exception
handling can be used as a program
Matt Miller [EMAIL PROTECTED] writes:
The idea is to allow a PL/pgSQL exception to not automatically rollback
the work done by the current block.
This fundamentally breaks the entire backend. You do not have the
option to continue processing after elog(ERROR); the (sub)transaction
rollback is
On Wed, 2005-08-03 at 16:25 -0400, Tom Lane wrote:
The idea is to allow a PL/pgSQL exception to not automatically
rollback the work done by the current block.
This fundamentally breaks the entire backend.
Yeah, but besides that, can you quick commit this to HEAD so I don't
have to keep
Matt Miller [EMAIL PROTECTED] writes:
On Wed, 2005-08-03 at 16:25 -0400, Tom Lane wrote:
You do not have the
option to continue processing after elog(ERROR); the (sub)transaction
rollback is necessary to clean up inconsistent state.
Okay, I'll look at this more closely. Can you give me an
