Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Daniel Farina <drfarina(at)acm(dot)org>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Hannu Krosing <hannu(at)krosing(dot)net>, Daniel Farina <dfarina(at)truviso(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION
Date: 2009-12-30 02:48:11
Message-ID: 603c8f070912291848x6cd0bbcck96af0cb75cd1e401@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 29, 2009 at 9:23 PM, Daniel Farina <drfarina(at)acm(dot)org> wrote:
> On Tue, Dec 29, 2009 at 5:57 PM, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2009-12-30 02:52:27 Thoughts on statistics for continuously advancing columns
Previous Message Hitoshi Harada 2009-12-30 02:46:40 Re: IntArray in c.h