Andres, * Andres Freund (andres@anarazel.de) wrote: > On 2017-04-05 21:07:59 -0400, Stephen Frost wrote: > > * Andres Freund (andres@anarazel.de) wrote: > > > I don't yet have a good idea how to deal with moving individual cells > > > into files, so they can be loaded. One approach would be to to have > > > something like > > > > > > \storequeryresult filename_template.%row.%column > > > > > > which'd then print the current query buffer into the relevant file after > > > doing replacement on %row and %column. > > > > I don't actually agree that there's a problem having the output from a > > query stored direclty in binary form into a single file. The above > > approach seems to imply that every binary result must go into an > > independent file, and perhaps that would be useful in some cases, but I > > don't see it as required. > > Well, it'd not be enforced - it'd depend on your template. But for a > lot of types of files, it'd not make sense to store multiple > columns/rows in file. Particularly for ones where printing them out to > files is actually meaningful (i.e. binary ones).
Having the template not require the row/column place-holders included strikes me as more likely to be confusing. My initial thinking around this was that users who actually want independent files would simply issue independent queries, while users who want to take a bunch of int4 columns and dump them into a single binary file would be able to do so easily.
I'm not against adding the ability for a single query result to be saved into independent files, but it strikes me as feature creep on this basic capability. Further, I don't see any particular reason why splitting up the output from a query into multiple files is only relevant for binary data.
The files can be simply joined together outside psql
Personally I prefer relation type: single field, single file in special g command - because I can simply off all formatting and result should be correct every time.
