Andres, * Andres Freund (and...@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
signature.asc
Description: Digital signature
