On Mon, 2009-11-23 at 18:31 -0500, Greg Smith wrote:
> Robert Haas wrote:
> > I'm fuzzy on what problem this is attempting to solve... as mentioned
> > in the above guidelines, it's usually good to start with some design
> > discussions before writing/submitting code.
> This has been through some heavy design discussions with a few PG
> hackers you know and some you don't, they just couldn't release the
> result until now. As for what it's good for, if you look at what you
> can do now with dblink, you can easily move rows between nodes using
> dblink_build_sql_insert. This is perfectly fine for small bits of work,
> but the performance isn't nearly good enough to do serious replication
> with it. The upper level patch here allows using COPY as the mechanism
> to move things between them, which is much faster for some use cases
> (which includes most of the really useful ones). It dramatically
> increases the scale of what you can move around using dblink as the
> replication transport.
>
> The lower level patch is needed to build that layer, which is an
> immediate proof of its utility. In addition, adding a user-defined
> function as a COPY target opens up all sorts of possibilities for things
> like efficient ETL implementation. And if this approach is accepted as
> a reasonable one, as Dan suggested a next step might even be to
> similarly allow passing COPY FROM through a UDF, which has the potential
> to provide a new efficient implementation path for some of the custom
> input filter requests that pop up here periodically.
Can this easily be extended to do things like
COPY stdin TO udf();
or
COPY udf() FROM stdin;
so that I could write a simple partitioning function, either local for
partitioned tables or using pl/proxy for partitioned databases
?
> --
> Greg Smith 2ndQuadrant Baltimore, MD
> PostgreSQL Training, Services and Support
> greg@2ndQuadrant.com www.2ndQuadrant.com
>
>