Re: Similar to csvlog but not really, json logs?
От | Tom Lane |
---|---|
Тема | Re: Similar to csvlog but not really, json logs? |
Дата | |
Msg-id | 18360.1409110327@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Similar to csvlog but not really, json logs? (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Similar to csvlog but not really, json logs?
Re: Similar to csvlog but not really, json logs? |
Список | pgsql-hackers |
Stephen Frost <sfrost@snowman.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
В списке pgsql-hackers по дате отправления: