On Wed, Sep 9, 2009 at 10:40 PM, Andrew Dunstan<and...@dunslane.net> wrote: > Robert Haas wrote: >> >> I wonder whether it would be appropriate to do something like >> implement a method by which copy could return text[] and then one >> could write wrappers around that functionality to do this as well as >> other things. > > It's not a function ... writing a copy() function returning text[] (or setof > text[], which would be better) in plperlu would be trivial. But it couldn't > read from stdin or be able to be fed data from a client in copy-in mode.
Yes, setof text[] is what I meant. Making it be able to read from stdin or be fed data from a client in copy-in mode would be the whole point of the feature, I suppose. > And even if we have it what does the sql look like to insert the values into > some table with n columns? INSERT INTO table SELECT t[1], t[2], t[3], t[4], ..., t[n] FROM (...however we get the copy results...) ...although I'm not entirely sure that's compatible with the client/server protocol. > Anything along these lines in C is likely to be far larger than what I had > in mind, which was a fairly minor enhancement. It wouldn't be the first time that someone was told that a particular enhancement didn't have enough value and that they had to do something larger if they wanted it in core, but on the other hand, I am only expressing my opinion, which is not binding on you or anyone else, nor even a fully-fleshed-out proposal. All I'm saying is that it seems to me that there is value in being able to use the CSV (or other) parsing code, but have some way to make modifications to how/where the data is actually inserted. However, I'm skeptical about whether the specific thing you want to do after parsing (namely, drop excess columns, null-fill missing ones) is sufficiently common to warrant a feature to do only that. YMMV, of course. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
