Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION |
Date | |
Msg-id | 603c8f070912291848x6cd0bbcck96af0cb75cd1e401@mail.gmail.com Whole thread Raw |
In response to | Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION (Daniel Farina <drfarina@acm.org>) |
Responses |
Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO
FUNCTION
Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION |
List | pgsql-hackers |
On Tue, Dec 29, 2009 at 9:23 PM, Daniel Farina <drfarina@acm.org> wrote: > On Tue, Dec 29, 2009 at 5:57 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> I am very fuzzy on where we stand with this patch. There's a link to >> the initial version on the commitfest application, but there has been >> so much discussion since then that I think there are probably some >> revisions to be made, though I can't say I know exactly what they are. >> >> I did also check the git branch, but it does not merge cleanly with the master. >> >> Is there a more recent version? Is this still under development? Or >> have we decided to go a different direction with it? > > I think we've decided to go in a different direction for > implementation, and my last communication was to suggest a mechanism > that would allow for something more clean using the copy options > refactoring. I wouldn't even attempt to merge it unless there's big > outcry for the feature as-is, which I doubt there is. But perhaps > it's worthy TODO fodder. > > The mechanics in the email you replied to probably need more feedback to act. I think there's clear support for a version of COPY that returns rows like a SELECT statement, particularly for use with CTEs. There seems to be support both for a mode that returns text[] or something like it and also for a mode that returns a defined record type. But that all seems separate from what you're proposing here, which is a considerably lower-level facility which seems like it would not be of much use to ordinary users, but might be of some value to tool implementors - or perhaps you'd disagree with that characterization? Anyway, my specific reaction to your suggestions in the email that I quoted is that it seems a bit baroque and that I'm not really sure what it's useful for in practice. I'm certainly not saying it ISN'T useful, because I can't believe that you would have gone to the trouble to work through all of this unless you had some ideas about nifty things that could be done with it, but I think maybe we need to back up and start by talking about the problems you're trying to solve, before we get too far down into a discussion of implementation details. It doesn't appear to me that's been discussed too much so far, although there's enough enthusiasm here to make me suspect that other people may understand it better than I do. Based on your comments above, I'm going to go ahead and mark this particular patch as Returned with Feedback, since it seems you don't intend to continue with it and therefore it won't need to be reviewed during the January CommitFest. But I'm interesting in continuing the discussion and in any new patches that come out of it. ...Robert
pgsql-hackers by date: