Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION - Mailing list pgsql-hackers

On Tue, Dec 29, 2009 at 9:11 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> I think we should try to put an interface layer in place in the first
> iteration.  I don't really see this as having much value without that.
>  If we implement this strictly as a series of COPY options, we're
> going to be committed to supporting that interface forever whether it
> turns out to be good for anything or not.  Since any such interface
> would pretty much have to be superuser-only, I'm inclined to think
> that there is not enough bang for the buck to justify the ongoing
> maintenance effort.

Interestingly, I came to the opposite conclusion you did: I thought
supporting new top-level syntax might be the more invasive and
support-heavy change as opposed to just changing the option handling
grammar to support funcall-looking things on the right-hand-side.

True, the semantics and interfaces between symbols would need to be
somewhat frozen and documented in either case. I do value in
supporting a notion of "this constellation of functions is OK, even if
one of them does take type INTERNAL", whereas my proposal has no
mechanism to address such a constellation: everything is independent,
which does not capture all the information necessary to determine if
it's safe to execute a particular combination of functions to perform
a COPY.

I think you may be right about this, so we could basically move most
things from the COPY option list into a new DDL option list...I am
more ambivalent, but it seems that would require a catalog, and so on,
which is why I did not leap to do that initially for the very
support-reasons you mentioned.

> One way to figure out whether we've define the COPY TARGET interface
> correctly is to put together a few sample implementations and see
> whether they seem functional and useful, without too many lacunas.  I
> think it should be possible to assess from a few such implementations
> whether we have basically the right design.

Okay, I was simply less optimistic than that (that we could get it
right so easily), and was content to put out something that had
reasonable design but perhaps byzantine (but well-defined) interfaces
and let complaints/wishes drive completion.

But given that the main difference between your proposal and mine is
to move things out of COPY's option list and into a toplevel DDL
option list, under the covers things are pretty samey, except I would
imagine your proposal requires committing to a new catalog(?) which
also enables addressing the combination of functions as a unit and a
new top-level DDL (but avoids committing to many new COPY options).

> I agree that needs some further thought.  Again, a few sample
> implementations might help provide clarity here.  I agree that the
> StringInfo representation is a bit random, but OTOH I mostly see
> someone installing a few COPY TARGET implementations into their DB and
> then using them over and over again.  Creating a new COPY TARGET
> should be relatively rare, so if they have to be written in C, we may
> not care that much.  On the flip side we should be looking for some
> concrete gain from putting that restriction into the mix.

I was originally inclined to agree, but I believe there are others who
the most interesting and use applications are only captured if
userland types are supported, and I can see good reason for that
belief...

Even something as simple as authoring "tee" for COPY will require
writing C here, whereas when supporting userland types people can hack
out a PL function that calls some other existing C-written functions
(we can provide a BYTEA veneer on top of the INTERNAL-version of a
function rather trivially express for this purpose...)

fdr