Re: Similar to csvlog but not really, json logs?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Similar to csvlog but not really, json logs?
Date: 2014-08-27 03:32:07
Message-ID: 18360.1409110327@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> Consider an audit system where which columns end up in the audit log are
> controlled by issuing ALTER TABLE .. ALTER COLUMN type statements.

<blink>

I'd like to consider such a thing, but it seems like utter pie in the
sky. Do you really believe that elog() could know enough about what it's
printing to apply such a filter? Do you think elog() should be allowed
to do catalog accesses in order to find out what the filter conditions
should be (hint: no)? Perhaps you think that we don't ever need to emit
error messages before we've analyzed a query enough to figure out which
tables are involved? Let alone which columns? Let alone which literals
elsewhere in the query string might be somehow associated with those
columns?

I suggest that you should spend most of your meeting tomorrow tamping down
hard on the expectations of whoever you're speaking with.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Arthur Silva 2014-08-27 03:41:05 Re: jsonb format is pessimal for toast compression
Previous Message Fujii Masao 2014-08-27 03:31:31 Re: Missing comment block at the top of streamutil.h and receivelog.h