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_adm
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
http:
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 broadcast)--
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
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 kee
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 giv
