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

On Wed, Dec 30, 2009 at 12:26 AM, Daniel Farina <drfarina@acm.org> wrote:
> 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.

Adding a catalog doesn't bother me a bit.  That doesn't really cost
anything.  What I'm concerned about in terms of maintenance is that
anything we support in 8.5 will likely have to be supported in 8.6,
8.7, 8.8, 8.9, and 8.10, and probably beyond that.  If we do something
that turns out to be CLEARLY a bad idea, then we MIGHT eventually be
able to get rid of it.  But we probably won't be that (un)lucky.
We're more likely to do something that's sorta-useful, but makes
future enhancements that we care about more difficult.  And then we'll
be stuck with it.  That's really what I care about avoiding.

In other words, it's OK if we add something now that may need to be
further extended in the future, but it's BAD if we add something now
that we want to change incompatibly or take out in the future.

> 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 with that summary.  I don't think the catalog is a problem
(though we need to make sure to get the dependency handling correct).
The additional DDL syntax is more likely to draw objections, although
perhaps unsurprisingly I don't have a problem with it personally.

>> 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...)

Sure.  If you think you can make it work using bytea, that seems
clearly better than using an internal type, all things being equal.

...Robert