"C. Bensend" <[EMAIL PROTECTED]> writes:
> So, just to be sure:
> 1) Start a %(&@#*(&% transaction
> 2) Set the column to NULL for all rows, undoing my stupidity
> 3) Issue the CORRECT SQL statement, and that will take care of the
> character conversion problem
> 4) COMMIT said transaction
> Always a good idea to do this kind of thing inside a BEGIN block ;-)
Yeah. That was the _second_ thing that came to mind. ;)
> As far as the system functions are concerned, you can just set the
> proacl column to NULL (ie, default) and that'll be fine for everything
> except the character co
"C. Bensend" <[EMAIL PROTECTED]> writes:
>The following erroneous command was entered:
> UPDATE pg_proc SET proacl = '{=}'
> ;
>.. instead of the correct one (missing the WHERE clause). It
> updated 1747 rows - oh crap.
Always a good idea to do this kind of thing inside a BEGIN block ;-)
Hey folks,
I just had a copy-n-paste mishap on one of my databases, while
fixing the character conversion problem.
The following erroneous command was entered:
UPDATE pg_proc SET proacl = '{=}'
;
.. instead of the correct one (missing the WHERE clause). It
updated 1747 rows - oh crap
Considering that this is a security-related system catalog update, is
there any way of providing some sort of signature for a message like
this such that the community can feel that issuing some arcane commands
as a superuser won't open a hole rather than close one?
This is the first time I've
Ich werde ab 27.04.2005 nicht im Büro sein. Ich kehre zurück am 09.05.2005.
Ich werde Ihre Nachricht nach meiner Rückkehr beantworten.
Meine Kollegen können Sie unter [EMAIL PROTECTED] erreichen.
Ursprüngliches Thema: [ANNOUNCE] IMPORTANT: two new PostgreSQL security problems found
I will be out of the office starting 29/04/2005 and will not return until
09/05/2005.
I will respond to your message when I return.
Institute of Physics
Registered charity No. 293851
76 Portland Place, London, W1B 1NT, England
IOP Publishing Limited
Registered in England under Registration N
Mauri Sahlberg <[EMAIL PROTECTED]> writes:
> I'm starting to become desperate. On saturday I dumped all databases,
> wiped whole postgresql installation. Installed newest rpms for Fedora 1,
> restored databases. Recompiled client libraries and binaries. Restarted
> and after five hours of operation
You probably want to
run the trigger "BEFORE UPDATE" unless you have some other code depending on the
value of modified_date during the update, and also instead of "RETURN NULL;" do
a "RETURN NEW;". Here's an example from one of my triggers:
Trigger
definition:
CREATE TRIGGER
trig_rec_re
On Mon, 02 May 2005 05:18:30 +0200, Enrico Weigelt wrote:
> I'd like to find out which queries are most expensive (taking very long or
> producing high load) in a running system, to see what requires further
> optimization. (the application is quite large and some more folks
> involved, so I cant
10 matches
Mail list logo
