The problem is that it's hard to read arbitrary formatted psql output from external program (not just gnuplot, but even especially written script). I made my scripts read few variations, but it doesn't look feasible to read all the combinations. For sure, it's possible to set format options inside macro, but then it would affect psql format options after execution.
This is why I think only one \graw option is just fine, because it produces stable machine-readable output.
Oh, I just get that in current state of \graw doesn't produce good machine-readable output.
# select '|', '|' \graw
|||
Column separator is character which can occur in values, and values aren't escaped. Thus, reader can't correctly divide values between columns in all the cases. So, I would rather like to see \graw to output in csv format with proper escaping.
current \graw implementation is pretty minimalistic
It is interesting topic - the client side csv support.
It can simplify lot of things
So, I see there is no arguing yet that exporting dataset from psql into a pipe in machine-readable format (presumably csv) would be an useful feature.
Are you going to revise your patch that way during this commitfest?
I'm marking this patch as "waiting for author" for now.
I hope so lot of people invite CSV support on client side. Some like:
psql -c "SELECT * FROM pg_class" --csv --header > pg_class.csv
Client side CSV formatting is significantly better idea. Unfortunately there are not clean how to do it. The basic question is: can we have 2 codes for CSV - server side/client side? If yes, then implementation should be trivial. If not, then I have not any idea.
We are able to generate html/tex/markdown formats on client side. CSV is more primitive, but much more important data format, so it should not be a problem. But I remember some objections related to code duplication.
