Re: Do we really want to migrate plproxy and citext into PG core distribution?
От | Hannu Krosing |
---|---|
Тема | Re: Do we really want to migrate plproxy and citext into PG core distribution? |
Дата | |
Msg-id | 1216913929.7001.44.camel@huvostro обсуждение исходный текст |
Ответ на | Re: Do we really want to migrate plproxy and citext into PG core distribution? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Do we really want to migrate plproxy and citext into
PG core distribution?
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: