Craig Ringer <cr...@2ndquadrant.com> wrote: > On 25 August 2017 at 15:12, Antonin Houska <a...@cybertec.at> wrote: > > How will this play with syslog? csvlog? etc?
There's nothing special about csvlog: the LogStream structure has a "destination" field, so if particular extension wants this kind of output, it simply sets the LOG_DESTINATION_CSVLOG bit here. LOG_DESTINATION_SYSLOG is a problem because (AFAIK) a single process can maintain no more than one connection to the syslog server. I don't like the idea of closing the current connection and opening a different one whenever the next ereport() is associated with a different stream than the previous was. As for LOG_DESTINATION_EVENTLOG, I haven't checked yet. > I wonder if a level of indirection is appropriate here, where extensions (or > postgres subsystems, even) provide a log stream label. Then the logging > backed takes care of using that appropriately for the logging mechanism in > use; for logging to file that'd generally be separate files. Same for > CSVlog. Other mechanisms could be left as stubs initially. > > So the outcome would be the same, just without the assumption of specific > file name and output mechanism baked in. The example I shown in my previous email was the simplest case I could think of. But it does not mean that the file name has to be hard-coded in the extension. Instead of setting the LogStream.filename field, you can pass a pointer to this field to DefineCustomStringVariable() function, so the specific GUC can control the value. -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://www.cybertec.at -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
