On Tue, 2008-07-22 at 17:24 -0400, Tom Lane wrote:
> In the case of plproxy, I think an integrated solution is pronounced
> "SQL-MED", and likewise plproxy in its present form doesn't move us
> toward that goal.
While pl/proxy can be tweaked into a way of achieving functionality of
SQL-MED ("SQL/MED provides extensions to SQL that define foreign-data
wrappers and datalink types to allow SQL to manage external data"), it
is in in no way more than a tiny piece of pl/proxy's possible
functionality.
As I see it, pl/proxy extends postgresql into yet another orthogonally
way of being "extensible", doing it in a well defined, but minimalist
way.
> An important point here is that acceptance of a feature into core (or
> even contrib) puts us on the hook to worry about upward compatibility
> for it, maybe not forever but for a long time into the future.
In some weird way, accepting any bigger piece of code into the "core"
often comes with its maintainer, thus providing scalability in the
maintenance front ;)
At least I'm sure that Marko will carry the main burden of maintaining
pl/proxy - maybe not forever but for a long time into the future.
> I don't think I want to buy into that for either of these as presently
> constituted --- they don't match up with what I think the long-term
> goals ought to be in these areas.
pl/proxy provides one way (often called "Sharding") of achieving
essentially unlimited scalability for a frequently occurring real-world
class of data management problems, while interfering minimally with
postgresql's internals. The "unlimited" part is especially true if
pl/proxy is used together with pg/bouncer.
I'm pretty sure that there is no general golden-bullet solution for
achieving this, and thus I can't see how pl/proxy can conflict with any
"long-term goals" in "these areas", for any value of "these areas".
pl/proxy also has some other possible uses, like doing callbacks in
independent transactions, simple remote calls, simple RO load balancing,
etc.
--------------------------
Hannu
