Re: Add support for logging the current role
От | Stephen Frost |
---|---|
Тема | Re: Add support for logging the current role |
Дата | |
Msg-id | 20110215180244.GD4116@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: Add support for logging the current role (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Add support for logging the current role
|
Список | pgsql-hackers |
* Andrew Dunstan (andrew@dunslane.net) wrote: > On 02/15/2011 11:13 AM, Stephen Frost wrote: > >Think I suggested that at one point. I'm all for doing that on a major > >version change like this one, but I think we already had some concerns > >about that on this thread (Andrew maybe?). > > I could live with it for a release if I thought we had a clear path > ahead, but I think there are some design issues that we need to > think about before we start providing for header lines and variable > formats in CSV logs, particularly w.r.t. log rotation etc. So I'm > slightly nervous about going ahead with this right now. I believe the suggestion that Robert and I were talking about above was to just unilatterally change the CSV log file output format to include current_role. No header lines, no variable output format, etc. I do think we can make header lines and variable output work, if we can get agreement on what the semantics should be. > You don't really make your case any better by continuing this > argument from years ago. I can tell you from experience that the CSV > HEADER feature is distinctly useful as it is. If you want to add a > mode that uses the header line as a column list on import, then make > that case, and I'll support it in fact, but it's not an alternative > to having the header ignored, which is a feature I would vigorously > resist removing. I'm not really interested in removing it. I guess I have a vain hope that with arguing I'll convince someone to take up the mantle of implementing the 'use header' option. :) Not getting much traction though, so I expect I'll work on it this summer. > (Incidentally, I think it won't be trivial - the > COPY code expects to know the columns by the time it opens the > file). Thanks for that insight, I'll take a look at how things work and see if I can come up with a sensible proposal. Thanks, Stephen
В списке pgsql-hackers по дате отправления: