Andres,
* Andres Freund (andres@anarazel.de) wrote:
> I don't like the API here much. Loading requires knowledge of some
> magic $1 value and allows only a single column, printing doesn't mean
> much when there's multiple columns / rows.
> I think the loading side of things should be redesigned into a more
> general facility for providing query parameters. E.g. something like
> \setparam $1 'whateva'
> \setparamfromfile $2 'somefile'
> \setparamfromprogram $3 cat /frakbar
>
> which then would get used in the next query sent to the server. That'd
> allow importing multiple columns, and it'd be useful for other purposes
> than just loading binary data.
I tend to agree that the loading side should probably be thought through
more.
> 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.
> I don't think we can find an API we agree upon in the next 48h...
Now that there's more than one opinion being voiced on the API, I tend
to agree with this. Hopefully we can keep the discussion moving
forward, however, as I do see value in this capability in general.
Thanks!
Stephen
