On 02/15/2011 11:13 AM, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
Well, I guess the other option is to just add it to the format, full
stop. But as someone pointed out previously, that's not a terribly
scalable solution, but perhaps it could be judged adequate for this
particular case.
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.
While I generally agree with the principal, I also wonder if it might
be better to just add this field in log_line_prefix and wait for
someone to complain about that as other than a theoretical matter.
I might be working against myself, but I'll complain right now about the
lack of any way to have a header on the CSV logs and that you don't get
to control what fields are logged. That said, I'm not currently using
them either, so my vote doesn't count for much. Of course, I'll also
complain about the lack of any way to get PG to respect the header,
forcing me to do fun things like:
for file in *results*; do
HEADER=`head -1 $file`
sed -e 's:""::g'< $file | \
psql -d beac -h sauron -c \
"\copy my_table ($HEADER) from STDIN with csv header"
done
on a regular basis. How forcing me to do that rather than asking
someone else to use 'tail -n +2' makes sense is beyond me..
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.
(Incidentally, I think it won't be trivial - the COPY code expects to
know the columns by the time it opens the file).
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
