From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
---|---|
To: | "Aleksander Alekseev" <a(dot)alekseev(at)postgrespro(dot)ru> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"Andrew Dunstan" <andrew(at)dunslane(dot)net>,"PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Better logging of COPY queries if log_statement='all' |
Date: | 2016-10-17 18:15:38 |
Message-ID: | 754a2e41-3324-42f7-acd4-d22c9b7a3ae6@mm |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Aleksander Alekseev wrote:
> According to my colleagues it would be very nice to have this feature.
> For instance, if you are trying to optimize PostgreSQL for application
> that uses COPY and you don't have access to or something like this.
> It could also be useful in some other cases.
Outside of the app, what can be already set up is an AFTER INSERT
FOR EACH ROW trigger that essentially does:
raise LOG, '%', NEW;
The main drawback of this approach is that, for each line of data
emitted to the log, there's another STATEMENT: copy... line added.
But that might be not too bad for certain uses.
Ideally we should be able to access the new rowset as a whole through
a statement-level trigger. In that case, the data could be logged in
a one-shot operation by that trigger.
There's a related item in the TODO list:
"Allow statement-level triggers to access modified rows"
and an old thread on -hackers here:
https://www.postgresql.org/message-id/20060522150647.GE24404@svana.org
that discussed this topic in relation to MSSQL having this functionality.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2016-10-17 18:33:34 | Re: COPY as a set returning function |
Previous Message | Tom Lane | 2016-10-17 18:14:23 | Re: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran |