Thread: Do we really want to migrate plproxy and citext into PG core distribution?
The current commitfest queue has two entries that propose to migrate existing pgfoundry projects (or improved versions thereof) into our core distribution. The more I think about this the less happy I am with it. From a maintenance point of view there seems little need for either project to get integrated: they don't appear to have much of any code that is tightly tied to backend innards. From a features point of view, yeah they're cool, but there are scads of cool things out there. From a project-management point of view, it's insanity to set a presumption that pgfoundry is just a proving ground for code that should eventually get into core once it's mature enough or popular enough or whatever. We *have to* encourage the development of a cloud of subprojects around the core, or core will eventually collapse of its own weight. We have not got the manpower to deal with an ever-inflating collection of allegedly "core" code. If anything, we ought to be working to push more stuff out of the core distro so that we can focus on the functionality that has to be there. So my feeling is that we should not accept either of these patches. Now, there is some value in submitting the code for review --- certainly citext is a whole lot better than it was a few weeks ago. I think it would be a good idea to be open to reviewing pgfoundry code with the same standards we'd use if we were going to integrate it. Perhaps commitfest is not the right venue for that, though, if only because of the possibility of confusion over what's supposed to happen. Comments? regards, tom lane
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Josh Berkus
Date:
Tom, > Comments? Well, in the *general* case, I think if we're going to have "first class" pgfoundry projects, then having a unified "official" Kitchen Sink Package will all of these add-ins becomes an imperative priority for 8.4. EDB's recent open sourcing of their installer might help with this. Futher, we would need to come up with some organized way to subject pgFoundry projects to the same level of general scrutiny which core code gets. Or at least close. In the specific cases of pl/proxy and citext, they are very much in line with what we already package with the core code, including things like dblink, ISN, and CIDR. citext in particular would eliminate a long-time newbie complaint about Postgres, but not if it's in an add-in package which the user can't find binaries for. So I would argue "maybe" on pl/proxy, but that citext does belong in core. --Josh Berkus
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"David E. Wheeler"
Date:
On Jul 21, 2008, at 12:43, Tom Lane wrote: > From a maintenance point of view there seems little need > for either project to get integrated: they don't appear to have much > of any code that is tightly tied to backend innards. Well, citext against CVS HEAD is quite different from the other version I maintain for 8.3. The latter copies the str_toloer() code out of formatting.c from CVS and adds a number of includes in order to get things to work the same as against HEAD. I could probably work around this, though, if there was a macro with the version number in it. > Now, there is some value in submitting the code for review --- > certainly > citext is a whole lot better than it was a few weeks ago. Absolutely. I really appreciate the feedback and comments I've received. Thank you! > I think it > would be a good idea to be open to reviewing pgfoundry code with the > same standards we'd use if we were going to integrate it. Perhaps > commitfest is not the right venue for that, though, if only because > of the possibility of confusion over what's supposed to happen. > > Comments? I think that this is a very good idea. But you might have trouble motivating people to review code that won't be in core unless it's managed very diligently. An official extended library distribution, as Josh suggests, would probably help with this, as it then becomes a project alongside PostgreSQL that bundles a lot of great add-ons, rather than just leaving all the add-ons to themselves on pgFoundry. Best, David
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"David E. Wheeler"
Date:
On Jul 21, 2008, at 12:53, Josh Berkus wrote: > In the specific cases of pl/proxy and citext, they are very much in > line with what we already package with the core code, including > things like dblink, ISN, and CIDR. citext in particular would > eliminate a long-time newbie complaint about Postgres, but not if > it's in an add-in package which the user can't find binaries for. > > So I would argue "maybe" on pl/proxy, but that citext does belong in > core. This is my view, as well. If it was in contrib, it'd go a long way toward addressing a commonly-requested feature, whereas things are much more difficult to find on pgFoundry. pgFoundry ain't the CPAN, alas. Even if users do find it in pgFoundry, the fact that it isn't in core is more likely to be seen as a red flag at this point. One might ask, why isn't it in core? What's wrong with it? Why is something that seems so useful relegated to pgFoundry? What's the usual quality of code on pgFoundry? Thanks for your consideration! Best, David
Josh Berkus <josh@agliodbs.com> writes: > So I would argue "maybe" on pl/proxy, but that citext does belong in core. Well, at least citext is pretty tiny ... regards, tom lane
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Andrew Dunstan
Date:
Tom Lane wrote: > The current commitfest queue has two entries that propose to migrate > existing pgfoundry projects (or improved versions thereof) into our > core distribution. The more I think about this the less happy I am > with it. From a maintenance point of view there seems little need > for either project to get integrated: they don't appear to have much > of any code that is tightly tied to backend innards. From a features > point of view, yeah they're cool, but there are scads of cool things > out there. From a project-management point of view, it's insanity > to set a presumption that pgfoundry is just a proving ground for code > that should eventually get into core once it's mature enough or popular > enough or whatever. I think there is a case to say that modules that are sufficiently popular have a case to be in core. That's not necessarily a large number, but there might well be a case for citext at least to be among the number at some stage. Surely a case insensitive text type has more general use than, say, the seg module. > We *have to* encourage the development of a cloud > of subprojects around the core, or core will eventually collapse of > its own weight. We have not got the manpower to deal with an > ever-inflating collection of allegedly "core" code. If anything, > we ought to be working to push more stuff out of the core distro so > that we can focus on the functionality that has to be there. > When we can get the much discussed module infrastructure that will make more sense. We will still need to keep enough modules to make sure that the infrastructure is working. In general I feel that the number of modules we have in core is about right. Maybe a small number should be pushed out. > So my feeling is that we should not accept either of these patches. > > Now, there is some value in submitting the code for review --- certainly > citext is a whole lot better than it was a few weeks ago. I think it > would be a good idea to be open to reviewing pgfoundry code with the > same standards we'd use if we were going to integrate it. Perhaps > commitfest is not the right venue for that, though, if only because > of the possibility of confusion over what's supposed to happen. > > Comments? > > If we don't have enough resources to maintain them do we have enough to review them? I was going to write some stuff about citext anyway. Quite apart from the above considerations I'm still a bit concerned about its performance characteristics. And I'm not sure we really want all the baggage that David is proposing to bring along with it. Is it an advance to force the regex_replace "i" flag for such a type? I can imagine cases where I might want it to sort insensitively, but be able to do case sensitive regex ops on it. It's not as if the user can't supply the flag. So right now I don't think citext should be included, because there are still issues to sort out, if for no other reason. cheers andrew
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Andrew Sullivan
Date:
On Mon, Jul 21, 2008 at 01:17:39PM -0700, David E. Wheeler wrote: > pgFoundry ain't the CPAN, alas. Maybe that's the problem that really needs solving? One of the big Postgres features is its extensibility. I agree that the extensions can sometimes be hard to find, but surely the answer to that is not an infinitely large source tarball? A -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"David E. Wheeler"
Date:
On Jul 21, 2008, at 13:19, Andrew Dunstan wrote: > I was going to write some stuff about citext anyway. Quite apart > from the above considerations I'm still a bit concerned about its > performance characteristics. And I'm not sure we really want all the > baggage that David is proposing to bring along with it. Is it an > advance to force the regex_replace "i" flag for such a type? I can > imagine cases where I might want it to sort insensitively, but be > able to do case sensitive regex ops on it. It's not as if the user > can't supply the flag. So right now I don't think citext should be > included, because there are still issues to sort out, if for no > other reason. I'm happy to work with folks to get them figured out, but at the end, there may be some differing opinions. If there's a reference implementation that could be checked (how does a case-insensitive collation work in another database?), that would be fine. You can use the "c" flag to get case-sensitive comparison with the regex functions, though not with the operators. (Maybe this should be moved to a separate thread?) Best, David
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"David E. Wheeler"
Date:
On Jul 21, 2008, at 13:28, Andrew Sullivan wrote: > Maybe that's the problem that really needs solving? > > One of the big Postgres features is its extensibility. I agree that > the extensions can sometimes be hard to find, but surely the answer to > that is not an infinitely large source tarball? Oh, of course. But one thing at a time. I'm in complete agreement that what goes into core should be pretty conservative, and that the module problem should be addressed. But even given that, I think that there is a strong case to be made that citext should be in contrib. Best, David
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Dave Cramer
Date:
On 21-Jul-08, at 4:28 PM, Andrew Sullivan wrote: > On Mon, Jul 21, 2008 at 01:17:39PM -0700, David E. Wheeler wrote: >> pgFoundry ain't the CPAN, alas. > > Maybe that's the problem that really needs solving? > > One of the big Postgres features is its extensibility. I agree that > the extensions can sometimes be hard to find, but surely the answer to > that is not an infinitely large source tarball? > > A > I'd have to agree with Andrew here. Making it easy to get extensions would solve lots of problems. Dave
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Peter Eisentraut
Date:
Am Monday, 21. July 2008 schrieb Tom Lane: > So my feeling is that we should not accept either of these patches. My feeling as well.
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Gregory Stark
Date:
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > From a project-management point of view, it's insanity to set a presumption > that pgfoundry is just a proving ground for code that should eventually get > into core once it's mature enough or popular enough or whatever. We *have > to* encourage the development of a cloud of subprojects around the core, or > core will eventually collapse of its own weight. One option might be the Perl approach of having separately developed projects which are snapshotted at stable points and included in the release. It has the chance to offer the best of both worlds by offloading development outside of core but provide users with a perceived "complete" system. For perl this is important because they want programmers to be able to assume certain modules are present. For postgres the case is less compelling since there isn't an interoperability issue. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support!
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"Dave Page"
Date:
On Tue, Jul 22, 2008 at 2:39 PM, Gregory Stark <stark@enterprisedb.com> wrote: > > "Tom Lane" <tgl@sss.pgh.pa.us> writes: > >> From a project-management point of view, it's insanity to set a presumption >> that pgfoundry is just a proving ground for code that should eventually get >> into core once it's mature enough or popular enough or whatever. We *have >> to* encourage the development of a cloud of subprojects around the core, or >> core will eventually collapse of its own weight. > > One option might be the Perl approach of having separately developed projects > which are snapshotted at stable points and included in the release. It has the > chance to offer the best of both worlds by offloading development outside of > core but provide users with a perceived "complete" system. Yeah, but then what happens when the offloaded development/maintenance doesn't happen? We'd end up pulling the package or having to maintain it ourselves anyway. /D -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Gregory Stark
Date:
"Dave Page" <dpage@pgadmin.org> writes: > On Tue, Jul 22, 2008 at 2:39 PM, Gregory Stark <stark@enterprisedb.com> wrote: >> >> "Tom Lane" <tgl@sss.pgh.pa.us> writes: >> >>> From a project-management point of view, it's insanity to set a presumption >>> that pgfoundry is just a proving ground for code that should eventually get >>> into core once it's mature enough or popular enough or whatever. We *have >>> to* encourage the development of a cloud of subprojects around the core, or >>> core will eventually collapse of its own weight. >> >> One option might be the Perl approach of having separately developed projects >> which are snapshotted at stable points and included in the release. It has the >> chance to offer the best of both worlds by offloading development outside of >> core but provide users with a perceived "complete" system. > > Yeah, but then what happens when the offloaded development/maintenance > doesn't happen? We'd end up pulling the package or having to maintain > it ourselves anyway. Yeah, it's probably a plan which would work better once there's some solidly maintained external projects for an extended period of time. I suppose it's not entirely unlike the history of tsearch. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services!
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Shane Ambler
Date:
Dave Cramer wrote: > > On 21-Jul-08, at 4:28 PM, Andrew Sullivan wrote: > >> On Mon, Jul 21, 2008 at 01:17:39PM -0700, David E. Wheeler wrote: >>> pgFoundry ain't the CPAN, alas. >> >> Maybe that's the problem that really needs solving? >> >> One of the big Postgres features is its extensibility. I agree >> that the extensions can sometimes be hard to find, but surely the >> answer to that is not an infinitely large source tarball? >> >> > I'd have to agree with Andrew here. Making it easy to get extensions > would solve lots of problems. What about starting a secondary team that would review extensions? Projects on pgfoundry could be identified as reviewed and approved as a type of recommendation that they are of acceptable quality to use in production - maybe against certain versions. What I would see is current core developers teaching a new group of developers to do the add-on code reviews to a point where they could continue on by themselves - one or two from core may wish to stay in this group - with core checking in from time to time to ensure the quality doesn't slip. Thereby giving some confidence in the use of the add-ons that get *certified*. A new add-on would be presented to this group and maybe voted on in one of the lists (General or Admin?) to get acceptance into the review process. Anyone interested in starting this? I do agree that the main code doesn't need to contain every feature that is available. But we do need to improve the perception of add-ons. Hardly anyone thinks twice about adding an extension to firefox, perl, gimp or oscommerce or even drivers to the os, and we need to aim for a similar thought here. I do think that having a list of reviewed and approved add-ons that is easily found on the main site along with release downloads will help along those lines. We need to promote that postgresql isn't a one-size-fits-all solution, it is a solid product that can be customised to suite your needs. -- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Simon Riggs
Date:
On Mon, 2008-07-21 at 15:43 -0400, Tom Lane wrote: > From a maintenance point of view there seems little need > for either project to get integrated: they don't appear to have much > of any code that is tightly tied to backend innards. This is a slightly circular argument. They have had to be written with no linkage to core to allow them to be created outside of it. I agree with your general principles on inclusion of features and also agree that in this specific case the patches should be rejected. Growing up outside of core cannot be a reason to exclude new capabilities from core, but it is probably a reason to reject specific code. In both these cases, I can see that the capability could be provided in a different way and benefit from tighter integration. I think we should return them with comments that if you integrate them more with core *and* can justify having done so, then we might include those features later. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"David E. Wheeler"
Date:
On Jul 22, 2008, at 12:51, Simon Riggs wrote: > I think we should return them with comments that if you integrate them > more with core *and* can justify having done so, then we might include > those features later I believe I've done both these things for citext, though if there is more to be done, I'm glad to do it. New patch coming later today, BTW. Thanks, David
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Josh Berkus
Date:
Tom, Simon, etc.: Of the several things which "PostgreSQL could learn from MySQL" which we covered at pgCon was that the requirement to hunt hither and yon for popular add-ins is one of the primary reasons for developers not using PostgreSQL. Further, one of the main reasons why people do use PostgreSQL is our advanced functionality. If we focus only on core SQL features, there are few reasons to use us over MySQL, Oracle express, SQL Server, or Firebird. Minimalism isn't its own reward. Obviously Tom has reason to worry about the overall maintenance effort for the PostgreSQL code. But we need to balance that against the need to add features that users want and will keep our community growing. If the way to do this is by packaging stuff together but maintaining separate CVS trees, then ok -- but then we need a plan for how we're going to do that, rather than just rejecting patches. The general case aside, I really feel strongly that citext belongs in core unless we come up with some other means to do case-insensitive text. It's one of the top 10 newbie questions. --Josh
Simon Riggs <simon@2ndquadrant.com> writes: > On Mon, 2008-07-21 at 15:43 -0400, Tom Lane wrote: >> From a maintenance point of view there seems little need >> for either project to get integrated: they don't appear to have much >> of any code that is tightly tied to backend innards. > This is a slightly circular argument. They have had to be written with > no linkage to core to allow them to be created outside of it. True, but in the form in which they are currently presented there is no (technical) reason to integrate them: no new capability would be provided thereby. Contrast with, say, text search, which we integrated mainly because we could provide easier configuration and a better dump/restore experience than the contrib module provided. > In both these cases, I can see that the capability could be provided in > a different way and benefit from tighter integration. Perhaps. I think a lot of the dump/restore issue could be solved generically if we had better "module" support ... but there's no need to go over that turf again right now. In the case of citext, I think an "integrated" solution would involve some way of creating case-insensitive collations, which would certainly be cool but it requires a whole lot of infrastructure we don't have yet. And it wouldn't look even a little bit like the present citext, nor be upward compatible with it. 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. 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. 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. regards, tom lane
Josh Berkus <josh@agliodbs.com> writes: > Tom, Simon, etc.: > Of the several things which "PostgreSQL could learn from MySQL" which we > covered at pgCon was that the requirement to hunt hither and yon for > popular add-ins is one of the primary reasons for developers not using > PostgreSQL. Agreed, but I think the best response to that is something CPAN-like for people to easily get hold of recognized extensions, and next best (or also) a "kitchen sink" installer package that agglomerates the core and selected outside projects. There aren't any successful extensible projects that ignore their own extensibility and put everything interesting into the core project. > The general case aside, I really feel strongly that citext belongs in > core unless we come up with some other means to do case-insensitive > text. It's one of the top 10 newbie questions. Maybe. I'd be happier about it if I could see a reasonable upgrade path from that to a SQL-spec-compliant solution (ie, something collation based). regards, tom lane
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"Joshua D. Drake"
Date:
On Tue, 2008-07-22 at 17:36 -0400, Tom Lane wrote: > Josh Berkus <josh@agliodbs.com> writes: > > Tom, Simon, etc.: > > Of the several things which "PostgreSQL could learn from MySQL" which we > > covered at pgCon was that the requirement to hunt hither and yon for > > popular add-ins is one of the primary reasons for developers not using > > PostgreSQL. > > Agreed, but I think the best response to that is something CPAN-like > for people to easily get hold of recognized extensions, and next best > (or also) a "kitchen sink" installer package that agglomerates the core > and selected outside projects. There aren't any successful extensible > projects that ignore their own extensibility and put everything > interesting into the core project. It seems to me a better solution is to have appropriate repositories for distributions that have them than some cpan style thing that is going to break package dependencies. apt-get install postgresql-plproxy portinstall (I think that is the command) postgresql-plproxy etc... makes more sense. Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
"Joshua D. Drake" <jd@commandprompt.com> writes: > On Tue, 2008-07-22 at 17:36 -0400, Tom Lane wrote: >> Agreed, but I think the best response to that is something CPAN-like >> for people to easily get hold of recognized extensions, > It seems to me a better solution is to have appropriate repositories for > distributions that have them than some cpan style thing that is going to > break package dependencies. Better than CPAN is no problem ;-). My point is just that we should exploit PG's extensibility rather than assume that everything interesting must wind up in the core tarball. > apt-get install postgresql-plproxy > portinstall (I think that is the command) postgresql-plproxy I believe Devrim already has a yum repository up and running for RPM-based distros, though I'm not sure he's got anything but the core packages in it (yet). regards, tom lane
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"Joshua D. Drake"
Date:
On Tue, 2008-07-22 at 17:54 -0400, Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: > > It seems to me a better solution is to have appropriate repositories for > > distributions that have them than some cpan style thing that is going to > > break package dependencies. > > Better than CPAN is no problem ;-). My point is just that we should > exploit PG's extensibility rather than assume that everything > interesting must wind up in the core tarball. Heh, o.k. :) > > > apt-get install postgresql-plproxy > > portinstall (I think that is the command) postgresql-plproxy > > I believe Devrim already has a yum repository up and running for > RPM-based distros, though I'm not sure he's got anything but the core > packages in it (yet). Well that was certainly part of my point. We have http://www.pgsqlrpms.org/ We also push (a ton) of packages up to EPEL. I also know that Peter has been working on something similar with SuSE and Debian. E.g; in short let's work with respective projects to get these as part of the repositories. Joshua D. Drake > > regards, tom lane > -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Simon Riggs
Date:
On Tue, 2008-07-22 at 14:06 -0700, Josh Berkus wrote: > Minimalism isn't its own reward. Obviously Tom has reason to worry > about the overall maintenance effort for the PostgreSQL code. But we > need to balance that against the need to add features that users want > and will keep our community growing. Well, minimalistic is a new compliment for me... ;-) Every time we add code to core, the next patch just got bigger since we must always include all aspects of the server features. I want to *increase* the extensibility of Postgres with plugins and APIs. When you mention what we could learn from MySQL, I would say introduce pluggable extensibility in more places. Solving the putting the pieces back together problem is a somewhat easier problem than trying to maintain a whole spittoon full of (cool) extensions in core. Do you want Tom to a) spend a month improving the optimizer b) get him to review already working code so we can package things It's a question of priorities. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Devrim GÜNDÜZ
Date:
On Tue, 2008-07-22 at 17:54 -0400, Tom Lane wrote: > > > apt-get install postgresql-plproxy > > portinstall (I think that is the command) postgresql-plproxy > > I believe Devrim already has a yum repository up and running for > RPM-based distros, though I'm not sure he's got anything but the core > packages in it (yet). I have about 50 packages there, and I do package many pgfoundry projects, like plproxy, pgsphere, pgpool, orafce, plpgpsm, table_log, etc. -- Devrim GÜNDÜZ devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org
"Joshua D. Drake" <jd@commandprompt.com> writes: > On Tue, 2008-07-22 at 17:54 -0400, Tom Lane wrote: >> I believe Devrim already has a yum repository up and running for >> RPM-based distros, though I'm not sure he's got anything but the core >> packages in it (yet). > Well that was certainly part of my point. We have > http://www.pgsqlrpms.org/ > ... > E.g; in short let's work with respective projects to get these as part > of the repositories. There's a limit to how far you can go there, because just about any distro (other than maybe Gentoo) is going to be resistant to dropping in bleeding-edge versions. *Especially* code that's not 99.44%+ compatible with what's in their current releases. To take the example I'm most closely familiar with: sure I can put the latest and greatest into Fedora rawhide, but that has approximately zip to do with what people are running in the field. As soon as a Fedora release happens, I'm constrained by compatibility issues as to what I can put into that branch. RHEL releases ten times more so. I gather that Debian, for instance, is even more paranoid than Red Hat about upstream version bumps. So I think the real-world situation is that we have to make stuff available to people who want to run something newer/different from what their chosen distro ships. That means providing our own repo. Certainly I've got no problem with pushing stuff to the official distros as fast as we can, but you've got to realize that that's gonna be a slow process, and necessarily always out of date for any distro version that is actually popular in the field. regards, tom lane
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"Joshua D. Drake"
Date:
On Tue, 2008-07-22 at 23:29 -0400, Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: > > On Tue, 2008-07-22 at 17:54 -0400, Tom Lane wrote: > >> I believe Devrim already has a yum repository up and running for > >> RPM-based distros, though I'm not sure he's got anything but the core > >> packages in it (yet). > > > Well that was certainly part of my point. We have > > http://www.pgsqlrpms.org/ > > ... > > E.g; in short let's work with respective projects to get these as part > > of the repositories. > > There's a limit to how far you can go there, because just about any > distro (other than maybe Gentoo) is going to be resistant to dropping in > bleeding-edge versions. Certainly. > *Especially* code that's not 99.44%+ compatible > with what's in their current releases. To take the example I'm most > closely familiar with: sure I can put the latest and greatest into > Fedora rawhide, but that has approximately zip to do with what people > are running in the field. We could have a quality committee? Something that says, "These 5 packages are considered stable by PGDG". Those go into the various repositories whether published directly to STABLE (or equiv) or are put into something like Universe. > So I think the real-world situation is that we have to make stuff > available to people who want to run something newer/different from what > their chosen distro ships. That means providing our own repo. > Yes that is what pgsqlrpms is. > Certainly I've got no problem with pushing stuff to the official distros > as fast as we can, but you've got to realize that that's gonna be a slow > process, and necessarily always out of date for any distro version that > is actually popular in the field. I should note that my point is about using proper package formats first, working with distros second. I am under no illusion that we will likely have to have our own repos (which is one of the reasons we have pgsqlrpms). The good news is, we have the beginnings of this already for at least three major distros. It should be relatively trivial to work with macports, fink and freebsd. I am sure the Open Solaris group would be more than happy to as well. Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
"Joshua D. Drake" <jd@commandprompt.com> writes: > On Tue, 2008-07-22 at 23:29 -0400, Tom Lane wrote: >> There's a limit to how far you can go there, because just about any >> distro (other than maybe Gentoo) is going to be resistant to dropping in >> bleeding-edge versions. > We could have a quality committee? Something that says, "These 5 > packages are considered stable by PGDG". Those go into the various > repositories whether published directly to STABLE (or equiv) or are put > into something like Universe. I don't think you got the point: such pronouncements would have exactly zero influence on Red Hat, or any other distro I'm familiar with. The *assumption* is that upstream thinks their new release is stable, else they wouldn't have made it. The distros are in the business of not believing that, until more proof emerges --- preferably from their own testing. I know that this is the mind-set at Red Hat, and I'm pretty sure SUSE and Debian work the same way. regards, tom lane
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"Joshua D. Drake"
Date:
On Wed, 2008-07-23 at 00:01 -0400, Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: > > On Tue, 2008-07-22 at 23:29 -0400, Tom Lane wrote: > >> There's a limit to how far you can go there, because just about any > >> distro (other than maybe Gentoo) is going to be resistant to dropping in > >> bleeding-edge versions. I actually think we are talking past each other. I know how distros work, all to well frankly. Our repos would be unofficial in the Redhat eye. My point is, the Red Hat eye is irrelevant for a project like this. Those who are going to confine themselves to that ideal are a lost cause (for this project). They will run ancient versions of PostgreSQL and that's cool because they feel they can trust it. On the other hand, those who need 8.3 (on RHEL4 for example) can get it, now -- without breaking compatibility and with RPM. Sincerely, Joshua D. Drake > > regards, tom lane > -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Peter Eisentraut
Date:
Am Wednesday, 23. July 2008 schrieb Tom Lane: > As soon as a Fedora release happens, I'm > constrained by compatibility issues as to what I can put into that > branch. RHEL releases ten times more so. I gather that Debian, for > instance, is even more paranoid than Red Hat about upstream version > bumps. Debian and Ubuntu have backport repositories that users can selectively refer to. SUSE has the openSUSE build service, which serves a similar function. So for these platforms, the infrastructure is there, and given infinite packaging hands (which we would need under any scheme, of course), all the packages in all the necessary versions can be provided through the right channels (defined as, where a user of the environment would look). So I don't think having our own repository is a problem or even desirable for these OS/distributions. And for Red Hat, we have pgsqlrpms.org, which already covers what you describe.
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"Greg Sabino Mullane"
Date:
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > Do you want Tom to > a) spend a month improving the optimizer > b) get him to review already working code so we can package things Actually, if the alternative is having the pieces outside of core where Tom never sees them, I'd vote for (b), as the optimizer already kicks ass but having Tom review other code is pretty invaluable. Code outside of core, is, in reality, less reviewed, less likely to work well with recent PG versions, and more likely to cause problems. It's also less likely to be found by people, less likely to be used by people, and less likely to be included by distros. Not to say that everything should get shoved into core, of course, but there are strong arguments for both sides. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200807231145 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkiHUlgACgkQvJuQZxSWSshURACg2MIfdH0cJOTf75HmuGEzlxo6 OBQAn21sqZ+rBEel1cf2dAIYpoWPHwW5 =Pj7J -----END PGP SIGNATURE-----
"Greg Sabino Mullane" <greg@turnstep.com> writes: > Code outside of core, is, in reality, less reviewed, less likely to work > well with recent PG versions, and more likely to cause problems. It's also > less likely to be found by people, less likely to be used by people, and > less likely to be included by distros. Not to say that everything should get > shoved into core, of course, but there are strong arguments for both sides. These are all true statements, of course, but ISTM they should be looked on as problems to be solved. Pushing stuff into core instead of solving these problems is not a scalable long-term answer. regards, tom lane
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"Matthew T. O'Connor"
Date:
Tom Lane wrote: > "Greg Sabino Mullane" <greg@turnstep.com> writes: >> Code outside of core, is, in reality, less reviewed, less likely to work >> well with recent PG versions, and more likely to cause problems. It's also >> less likely to be found by people, less likely to be used by people, and >> less likely to be included by distros. Not to say that everything should get >> shoved into core, of course, but there are strong arguments for both sides. > > These are all true statements, of course, but ISTM they should be looked > on as problems to be solved. Pushing stuff into core instead of solving > these problems is not a scalable long-term answer. A few random thoughts... The application that comes to mind first for me when you talk plugins is Firefox. They make it very easy to browse for plugins and to install, update, remove them. Their plug-in system also tries to account for Firefox version and OS platform which we would need to do also. Perhaps one thing that would help PostgreSQL plug-ins is a nice GUI plug-in browser and management application. The logical place to add this IMHO is PGAdmin since it is GUI, already talks to the DB and is cross platform. I'm not saying a GUI should be required to manage plug-ins, a fully CLI option should be made available too.
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"Marko Kreen"
Date:
On 7/23/08, Greg Sabino Mullane <greg@turnstep.com> wrote: > > Do you want Tom to > > a) spend a month improving the optimizer > > b) get him to review already working code so we can package things > > Actually, if the alternative is having the pieces outside of core where > Tom never sees them, I'd vote for (b), as the optimizer already kicks ass > but having Tom review other code is pretty invaluable. > > Code outside of core, is, in reality, less reviewed, less likely to work > well with recent PG versions, and more likely to cause problems. It's also > less likely to be found by people, less likely to be used by people, and > less likely to be included by distros. Not to say that everything should get > shoved into core, of course, but there are strong arguments for both sides. Agreed. But PL/Proxy has one additional problem. First, it's a small & simple clustering solution that plays very well on Postgres strengths - transparent plan cache in functions, transactional DDL, etc. It allows significantly higher uptime and query-per-sec than any "plain sql" solution. But it has serious weakness - it is not "transparent", user needs to change it's coding style to function-based one. (This is related to the small-and-simple property.) So, for it to be useful, the users need to be aware of it as early in development as possible. And the idea to turn pgfoundry into CPAN is pointless. An user may willing to throw random modules to his random perl script, but not to his whole db architecture. So it needs to be either in main distro or nearby it. OTOH, the most serious argument against PL/Proxy merge is that when we do remote tables/views based on SQL-MED, it's quite natural to extend that on functions, thus making plproxy redundant. OTOH^2, there has not been any serious thinking on that direction AFAICS, except how "dbi-link can push down WHERE clause", This suggests it wont appear before 2011... Not that its a argument for merge, but maybe pushing it to an "all-presentable-extensions" package and having proper review done would be a good idea. -- marko
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Dimitri Fontaine
Date:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, As a potential user of the solution, I'd very much like to have plproxy into -core if possible and sensible. Knowing nothing about the "sensible" part, I'd vote for inclusion. But whether -core vote for or against inclusion, I'd appreciate to have a module or package notion into PostgreSQL and a tool to easily install existing extensions, which would build on PGXS extension system to build on the fly code version compatible with current major PG version : pg_pkg add-mirror http://packages.postgresql.org/ pg-pkg list [remote | available] pg_pkg add plproxy prefixcitext pg_pkg install plproxy mydatabase pg_pkg uninstall [--force] plproxy mydatabase .. Of course details about PostgreSQL module/package management belongs to some other thread, I'll try to browse our archives to see where we are on this point and to propose a summary and some ideas if necessary. Any reader willing to share good starting points? :) I think having something to easily manage PostgreSQL modules/packages (including contribs ones) would change the matter here. If it was easy to fetch a list of -core reviewed or supported extensions and to install them on ones databases, having plproxy not included in -core would be an *easy* decision to make. Le 23 juil. 08 à 19:54, Marko Kreen a écrit : > appear before 2011... Not that its a argument for merge, but maybe > pushing it to an "all-presentable-extensions" package and having > proper > review done would be a good idea. Now, it seems to me we already have a place where to distribute reviewed code, maintained by non-core hackers and integrated into distributions and documentation of PostgreSQL: contrib. Maybe contrib (plans to get a better name ongoing? extra, extension, anything less remote then current naming) would fit the bill here as a good compromise? Sorry to raise unwanted subjects, please do not feed the trolls (in this thread at least) :) - -- Dimitri Fontaine -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkiHgCUACgkQlBXRlnbh1blP8ACgmKWAN4PyOSUQdl9hM+vZV0xK PJYAn1OmTreVxrqjDxsTcjGiNFO/30ok =SYGB -----END PGP SIGNATURE-----
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Peter Eisentraut
Date:
Am Wednesday, 23. July 2008 schrieb Marko Kreen: > And the idea to turn pgfoundry into CPAN > is pointless. An user may willing to throw random modules to his > random perl script, but not to his whole db architecture. Based on what reasoning?
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"Marko Kreen"
Date:
On 7/24/08, Peter Eisentraut <peter_e@gmx.net> wrote: > Am Wednesday, 23. July 2008 schrieb Marko Kreen: > > And the idea to turn pgfoundry into CPAN > > is pointless. An user may willing to throw random modules to his > > random perl script, but not to his whole db architecture. > > Based on what reasoning? Based on my own behaviour. -- marko
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Hannu Krosing
Date:
On Wed, 2008-07-23 at 12:38 -0400, Tom Lane wrote: > "Greg Sabino Mullane" <greg@turnstep.com> writes: > > Code outside of core, is, in reality, less reviewed, less likely to work > > well with recent PG versions, and more likely to cause problems. It's also > > less likely to be found by people, less likely to be used by people, and > > less likely to be included by distros. Not to say that everything should get > > shoved into core, of course, but there are strong arguments for both sides. > > These are all true statements, of course, but ISTM they should be looked > on as problems to be solved. Pushing stuff into core instead of solving > these problems is not a scalable long-term answer. And being in core does in no way guarantee reviews and updates if stuff changes in the backend, as long as regression tests pass - as a proof take a look at pl/python ugliness. it has not been updated in any major way since it was first written and so does not make use of any newer ways of writing PLs. I am currently working on get this fixed, looking, ironically, much at pl/proxy code to do so. I was away from net for last 3 weeks, (climbed mt. Elbrus) but I'll get my patches brushed up in 2-3 weeks to bring pl/python on par with other PLs. OTOH, until we have solid foundation for believing that we can move all (or at least most) PLs out of core, I'd like pl/proxy to be "in the core", at least "being in the core CVS" sense. -------------- Hannu
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Hannu Krosing
Date:
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
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"Joshua D. Drake"
Date:
On Thu, 2008-07-24 at 18:38 +0300, Hannu Krosing wrote: > 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. > 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, These are all excellent points but I think the real problem here is: There is nothing that requires pl/proxy to be in core. Everyone already agrees pl/proxy is very cool technology for PostgreSQL. I used to make a lot of arguments about pushing things into core, I was big fanboy of getting Tsearch2 into core. Looking back and getting older and wiser (no laughing :P) I realize that its almost kind of silly to keep pushing this stuff into core. Lots of people talk about legitimacy of the package or some sort of artificial endorsement that gets created by being in core. Some of it is personal, it is a big feeling of pride to have a piece of code accepted to core. It is also a way to beef up the resume and yes generally a way to deal with more ignorant hosting shops that won't install external modules. However this is not a core problem. It is not a hacker problem. It is and education and advocacy problem. We don't need pl/proxy in core. What pl/proxy needs is a solid project of its own, with good documentation, and community members. Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Hannu Krosing
Date:
On Thu, 2008-07-24 at 09:06 -0700, Joshua D. Drake wrote: > On Thu, 2008-07-24 at 18:38 +0300, Hannu Krosing wrote: > > 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. > > > 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, > > These are all excellent points but I think the real problem here is: > > There is nothing that requires pl/proxy to be in core. AFAIK, there is nothing that requires pl/perl, pl/tcl or pl/python to be in core either. Actually, I think that being an independent language / postgresql extension tool, pl/proxy is _more_ fit to be in core than external language adapters. And it would be nice, if some well-maintained sample language (pl/sh or even pl/dummy) which serves as a sample of latest ways to make use of pl/function support in core pg code would be included in core as well. with some slight restructuring (separation of pl-clue and actrual cacheing/execution) pl/proxy could serve this space as well > Everyone already agrees pl/proxy is very cool technology for PostgreSQL. > > I used to make a lot of arguments about pushing things into core, I was > big fanboy of getting Tsearch2 into core. Looking back and getting older > and wiser (no laughing :P) I realize that its almost kind of silly to > keep pushing this stuff into core. Not silly at all. Tsearch in core seems a wise choice, as well as _some_ implementation of multiple locales. > Lots of people talk about legitimacy of the package or some sort of > artificial endorsement that gets created by being in core. Some of it is > personal, it is a big feeling of pride to have a piece of code accepted > to core. Usually it is also a way of getting the _core_ better/more functional. > It is also a way to beef up the resume and yes generally a way > to deal with more ignorant hosting shops that won't install external > modules. > > However this is not a core problem. It is not a hacker problem. It is > and education and advocacy problem. We don't need pl/proxy in core. What > pl/proxy needs is a solid project of its own, with good documentation, > and community members. As mentioned in another mail, we don't _need_ other pl-s (except maybe pl/pgsql) to be in core either. And it is an additional bonus for consultants, if we keep some of the best parts separate ;) ----------------- Hannu PS. Thinking more of it, I don't even understand, what it means for a PL to be "in core" ;) Are they are under src/pl just for the reason that there is not contrib/pl ? Does pushing something into core give impression of trying to get rid of the responsibility of managing that piece of code ? ------------------ Hannu
Hannu Krosing <hannu@krosing.net> writes: > On Thu, 2008-07-24 at 09:06 -0700, Joshua D. Drake wrote: >> These are all excellent points but I think the real problem here is: >> There is nothing that requires pl/proxy to be in core. > AFAIK, there is nothing that requires pl/perl, pl/tcl or pl/python to be > in core either. True, but I think it's a good idea to have at least one such in core, as a prototype to help us track the issues associated with loading a large third-party library along with a PL. The fact that we have three is historical, but on the other hand I believe we've seen distinct issues crop up from each one, so maybe only one isn't enough either. > Actually, I think that being an independent language / postgresql > extension tool, pl/proxy is _more_ fit to be in core than external > language adapters. It teaches us nothing about connecting to outside code, though. > And it would be nice, if some well-maintained sample language (pl/sh or > even pl/dummy) which serves as a sample of latest ways to make use of > pl/function support in core pg code would be included in core as well. And why do you think the above three don't serve that purpose? Or even more to the point, how likely is it that an unused "dummy" language would be well-maintained? regards, tom lane
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"Robert Haas"
Date:
On Thu, Jul 24, 2008 at 4:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Hannu Krosing <hannu@krosing.net> writes: >> On Thu, 2008-07-24 at 09:06 -0700, Joshua D. Drake wrote: >>> These are all excellent points but I think the real problem here is: >>> There is nothing that requires pl/proxy to be in core. > >> AFAIK, there is nothing that requires pl/perl, pl/tcl or pl/python to be >> in core either. > > True, but I think it's a good idea to have at least one such in core, > as a prototype to help us track the issues associated with loading a > large third-party library along with a PL. The fact that we have three > is historical, but on the other hand I believe we've seen distinct > issues crop up from each one, so maybe only one isn't enough either. ISTM that if that if you're willing to admit, even with caveats, that PL/perl, PL/tcl, or PL/python doesn't "need" to be in core, then excluding anything else from core on the basis that it doesn't need to be there is silly. The extent to which the feature is useful to a large number of users (or not) and the extent to which it complicates maintenance of the code base (or not) seem like much more important issues. ...Robert
"Robert Haas" <robertmhaas@gmail.com> writes: > ISTM that if that if you're willing to admit, even with caveats, that > PL/perl, PL/tcl, or PL/python doesn't "need" to be in core, then > excluding anything else from core on the basis that it doesn't need to > be there is silly. You are merely setting up a straw man, as no one has suggested such a policy. Any specific decision of this type is going to involve a combination of factors, and that's only one. regards, tom lane
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"Josh Tolley"
Date:
On Thu, Jul 24, 2008 at 2:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Hannu Krosing <hannu@krosing.net> writes: >> And it would be nice, if some well-maintained sample language (pl/sh or >> even pl/dummy) which serves as a sample of latest ways to make use of >> pl/function support in core pg code would be included in core as well. > > And why do you think the above three don't serve that purpose? Or even > more to the point, how likely is it that an unused "dummy" language > would be well-maintained? For whatever it's worth, I'm in the middle of writing a PL (PL/LOLCODE, specifically), and have found helpful examples of how to do stuff in PL/pgSQL, PL/Perl, *and* pl/proxy. The examples in the documentation followed by a bunch of hair pulling while reading PL/pgSQL were enough to get started, without the benefit of a dummy language. That's not to say that a dummy language wouldn't be useful, only that for a coder of my caliber (i.e. Not Terribly Skilled but Able to Code Myself Out of a Wet Paper Bag) it wasn't necessary. Because pl/proxy is not in core, I didn't immediately look to it for examples, but was pointed there by a helpful soul on IRC. My own opinion is that though there have been several in recent years, new PLs are written rarely enough that "best practices" don't change a whole lot. PL/Perl and PL/pgSQL particularly are very well maintained, and thus demonstrate in most cases a perfectly acceptable way of writing a PL. As to whether or not pl/proxy should be in core, I have no particular opinion. PL/LOLCODE probably should not be. :) - Josh / eggyknap
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"Asko Oja"
Date:
Hi
One of reasons to get PL/proxy into core is to make it available to Windows users also.
The idea is to get to the situation
createlang plproxy mydb
If we can achieve this without putting plproxy into core then i would like to hear how.
Asko
One of reasons to get PL/proxy into core is to make it available to Windows users also.
The idea is to get to the situation
createlang plproxy mydb
If we can achieve this without putting plproxy into core then i would like to hear how.
Asko
On Fri, Jul 25, 2008 at 2:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Robert Haas" <robertmhaas@gmail.com> writes:You are merely setting up a straw man, as no one has suggested such a
> ISTM that if that if you're willing to admit, even with caveats, that
> PL/perl, PL/tcl, or PL/python doesn't "need" to be in core, then
> excluding anything else from core on the basis that it doesn't need to
> be there is silly.
policy. Any specific decision of this type is going to involve a
combination of factors, and that's only one.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"Joshua D. Drake"
Date:
On Fri, 2008-07-25 at 09:37 +0300, Asko Oja wrote: > Hi > > One of reasons to get PL/proxy into core is to make it available to > Windows users also. > The idea is to get to the situation > > createlang plproxy mydb > > If we can achieve this without putting plproxy into core then i would > like to hear how. If the installer project wants to use it on Windows they can. Of course that assumes that it runs on windows (I have no idea if it does). Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Andrew Dunstan
Date:
Asko Oja wrote: > Hi > > One of reasons to get PL/proxy into core is to make it available to > Windows users also. > The idea is to get to the situation > > createlang plproxy mydb > > If we can achieve this without putting plproxy into core then i would > like to hear how. The same way you would for any other module. This is a non-argument. If you want to be able to do it without building your own, then you would need to ask the Windows Installer guys (Dave and Magnus) to include it - they already include lots of non-core stuff, including at least one PL, IIRC. cheers andrew
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Alvaro Herrera
Date:
> On Fri, 2008-07-25 at 09:37 +0300, Asko Oja wrote: > > One of reasons to get PL/proxy into core is to make it available to > > Windows users also. > > The idea is to get to the situation > > > > createlang plproxy mydb > > > > If we can achieve this without putting plproxy into core then i would > > like to hear how. Sounds like you just need to get a new row in the standard pg_pltemplate. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Re: Do we really want to migrate plproxy and citext intoPG core distribution?
From
"Hiroshi Saito"
Date:
Hi. I tackled with hope temporarily. It seems that some adjustment is still required. http://winpg.jp/~saito/pg_work/plproxy/ However, windows user desires to use. Of course, it is also me. Regards, Hiroshi Saito From: "Joshua D. Drake" <jd@commandprompt.com> > On Fri, 2008-07-25 at 09:37 +0300, Asko Oja wrote: >> Hi >> >> One of reasons to get PL/proxy into core is to make it available to >> Windows users also. >> The idea is to get to the situation >> >> createlang plproxy mydb >> >> If we can achieve this without putting plproxy into core then i would >> like to hear how. > > If the installer project wants to use it on Windows they can. Of course > that assumes that it runs on windows (I have no idea if it does).
Re: Do we really want to migrate plproxy and citext intoPG core distribution?
From
Andrew Dunstan
Date:
Hiroshi Saito wrote: > Hi. > > I tackled with hope temporarily. It seems that some adjustment is > still required. > http://winpg.jp/~saito/pg_work/plproxy/ > However, windows user desires to use. Of course, it is also me. What is stopping you? Whether or not it works on Windows has (or should have) nothing to do with whether or not it is in core. Regarding your patch, the change w.r.t. the CONST token looks a bit odd - can you explain what you're doing and why? cheers andrew >
Alvaro Herrera <alvherre@commandprompt.com> writes: >> On Fri, 2008-07-25 at 09:37 +0300, Asko Oja wrote: >>> createlang plproxy mydb >>> >>> If we can achieve this without putting plproxy into core then i would >>> like to hear how. > Sounds like you just need to get a new row in the standard pg_pltemplate. When pg_pltemplate was first proposed, we discussed including entries in its standard contents for all the known non-core PLs. I forget the arguments that were made against that, but I still think it'd be a good idea. It'd save one step in installing a non-core PL, and the entries couldn't cause any harm, since they'd be useless unless the admin had actually installed the corresponding .so into the installation's $libdir. regards, tom lane
Re: Do we really want to migrate plproxy and citext intoPG core distribution?
From
"Hiroshi Saito"
Date:
> What is stopping you? Whether or not it works on Windows has (or should > have) nothing to do with whether or not it is in core. I think that plproxy is great. However, the windows user did not complain. Because, build was not easy. Therefore, pginstaller has not chosen. Then, I thought that I wanted to solve....but, I do not have a spare time. Are they unrelated? I'm sorry if it is a noise.... > > Regarding your patch, the change w.r.t. the CONST token looks a bit odd > - can you explain what you're doing and why? Ad hoc in order to clarify a problem. Regards, Hiroshi Saito
Tom Lane wrote: > Hannu Krosing <hannu@krosing.net> writes: >> AFAIK, there is nothing that requires pl/perl, pl/tcl or pl/python to be >> in core either. > > True, but I think it's a good idea to have at least one such in core, > as a prototype to help us track the issues associated with loading a > large third-party library along with a PL. The fact that we have three > is historical, but on the other hand I believe we've seen distinct > issues crop up from each one, so maybe only one isn't enough either. Wouldn't it provide even more benefit if these were maintained as independent modules *outside* of core but still by the core team. That would not only help track issues of loading the library as Tom described; but also issues related to maintaining external modules.
Ron Mayer <rm_pg@cheapcomplexdevices.com> writes: > Wouldn't it provide even more benefit if these were maintained > as independent modules *outside* of core but still by the core team. This part of the core team isn't willing to do that. I've got enough work to do without trying to keep multiple repositories in sync. regards, tom lane
Re: Do we really want to migrate plproxy and citext intoPG core distribution?
From
"Marko Kreen"
Date:
On 7/25/08, Hiroshi Saito <z-saito@guitar.ocn.ne.jp> wrote: > I tackled with hope temporarily. It seems that some adjustment is still > required. > http://winpg.jp/~saito/pg_work/plproxy/ > However, windows user desires to use. Of course, it is also me. > Regards, > Hiroshi Saito Thanks, I applied the patch to CVS, with minor changes: - Use HAVE_SYS_SELECT_H instead of WIN32 for <sys/select.h> - Do SHLIB_LINK += instead of separate var. Could you please test the attached patch or CVS HEAD, whether everything works fine now? Btw, do not worry about regtest failure in plproxy_many, this is due to differences in system random() function. The test should rewritten, although I have not yet decided how... -- marko
Attachment
Re: Do we really want to migrate plproxy and citext intoPG core distribution?
From
"Marko Kreen"
Date:
On 7/28/08, Marko Kreen <markokr@gmail.com> wrote: > On 7/25/08, Hiroshi Saito <z-saito@guitar.ocn.ne.jp> wrote: > > I tackled with hope temporarily. It seems that some adjustment is still > > required. > > http://winpg.jp/~saito/pg_work/plproxy/ > > However, windows user desires to use. Of course, it is also me. > > Regards, > > Hiroshi Saito > > Thanks, I applied the patch to CVS, with minor changes: > - Use HAVE_SYS_SELECT_H instead of WIN32 for <sys/select.h> > - Do SHLIB_LINK += instead of separate var. > > Could you please test the attached patch or CVS HEAD, > whether everything works fine now? One more change - I replaced __attribute__((dllimport)) with PGDLLIMPORT, which seems more standard. -- marko
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"Asko Oja"
Date:
<div dir="ltr">Hi hackers<br /><br />Just my non hacker view on the pl/proxy matter.<br /><br /> From FAQ:<br /> PL/Proxyis compact language for remote calls between PostgreSQL databases. <br /><br /> Why we submitted pl/proxy into coreat all?<br /> 1. Current core distribution contains dblink which sucks both usability wise and security wise but beingpart of core distribution will be first thing people are going to try out. We wanted to save people losing couple ofdays trying out dblink before looking for other alternatives like it happend with us.<br /> 2. Various languages are partof core distribution and pl/proxy by adding possibility to call remotely procedures created with these languages seemsto be logical extension to PostgreSQL in general. And it makes it essential for pl/proxy to stay compatible with allthe developments in function calling syntax.<br />3. And last but not least to make it easier to use for whoever who mightneed to do remote procedure calls between PostgreSQL servers.<br /><br /> So i rephrase your question:<br /> Would capabilityto do remote procedure calls useful addition to PostgreSQL feature set?<br /><br /> In my experience when organizationgrows out of one database on one server remote calls are needed quite soon. <br /><br />About citext. Skype isusing various hacks and workarounds because there was no such type in PostgreSQL and i understand others also. To me itseems to be choice between couple of developers doing it once and for all and hundreds of developers inventing the wheelevery day and not to mention hours spent debugging over various layers of applications. It just shows how hackers havetotally different point of view on things from people who are using the program:) But again i am just a manager andshould be lower than grass in hackers list :)<br /><br /> regards.<br /> Asko<br /> skype: askoja<br /><br /> PS: I amsorry for this reply coming so late didn't want to spoil my vacation :)<br /><br /><div class="gmail_quote">On Mon, Jul21, 2008 at 10:43 PM, Tom Lane <span dir="ltr"><<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>></span>wrote:<br /><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> The current commitfest queuehas two entries that propose to migrate<br /> existing pgfoundry projects (or improved versions thereof) into our<br/> core distribution. The more I think about this the less happy I am<br /> with it. From a maintenance point ofview there seems little need<br /> for either project to get integrated: they don't appear to have much<br /> of any codethat is tightly tied to backend innards. From a features<br /> point of view, yeah they're cool, but there are scadsof cool things<br /> out there. From a project-management point of view, it's insanity<br /> to set a presumption thatpgfoundry is just a proving ground for code<br /> that should eventually get into core once it's mature enough or popular<br/> enough or whatever. We *have to* encourage the development of a cloud<br /> of subprojects around the core,or core will eventually collapse of<br /> its own weight. We have not got the manpower to deal with an<br /> ever-inflatingcollection of allegedly "core" code. If anything,<br /> we ought to be working to push more stuff out of thecore distro so<br /> that we can focus on the functionality that has to be there.<br /><br /> So my feeling is that weshould not accept either of these patches.<br /><br /> Now, there is some value in submitting the code for review --- certainly<br/> citext is a whole lot better than it was a few weeks ago. I think it<br /> would be a good idea to be opento reviewing pgfoundry code with the<br /> same standards we'd use if we were going to integrate it. Perhaps<br /> commitfestis not the right venue for that, though, if only because<br /> of the possibility of confusion over what's supposedto happen.<br /><br /> Comments?<br /><br /> regards, tom lane<br /><font color="#888888"><br/> --<br /> Sent via pgsql-hackers mailing list (<a href="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br/> To make changes to your subscription:<br/><a href="http://www.postgresql.org/mailpref/pgsql-hackers" target="_blank">http://www.postgresql.org/mailpref/pgsql-hackers</a><br/></font></blockquote></div><br /></div>
Re: Do we really want to migrate plproxy and citext intoPG core distribution?
From
"Hiroshi Saito"
Date:
Hi Marko-san. Great thanks!! Please correct one mistake of mine...sorry. This patch solved problem of win32.:-) Regards, Hiroshi Saito ----- Original Message ----- From: "Marko Kreen" <markokr@gmail.com> > On 7/28/08, Marko Kreen <markokr@gmail.com> wrote: >> On 7/25/08, Hiroshi Saito <z-saito@guitar.ocn.ne.jp> wrote: >> > I tackled with hope temporarily. It seems that some adjustment is still >> > required. >> > http://winpg.jp/~saito/pg_work/plproxy/ >> > However, windows user desires to use. Of course, it is also me. >> > Regards, >> > Hiroshi Saito >> >> Thanks, I applied the patch to CVS, with minor changes: >> - Use HAVE_SYS_SELECT_H instead of WIN32 for <sys/select.h> >> - Do SHLIB_LINK += instead of separate var. >> >> Could you please test the attached patch or CVS HEAD, >> whether everything works fine now? > > One more change - I replaced __attribute__((dllimport)) with PGDLLIMPORT, > which seems more standard. > > -- > marko > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers
Re: Do we really want to migrate plproxy and citext intoPG core distribution?
From
"Marko Kreen"
Date:
On 7/28/08, Hiroshi Saito <z-saito@guitar.ocn.ne.jp> wrote: > Please correct one mistake of mine...sorry. > This patch solved problem of win32.:-) You mean the += -lws2_32 must be after PGXS? Ok, but moving the PGXS line is not right as it should after all variables are set. I moved the SHLIB_LINK += line instead. Please test. -- marko
Re: Do we really want to migrate plproxy and citext intoPG core distribution?
From
"Hiroshi Saito"
Date:
Hi Marko-san. Thanks! It is comfortable.:-) Regards, Hiroshi Saito ----- Original Message ----- From: "Marko Kreen" <markokr@gmail.com> > On 7/28/08, Hiroshi Saito <z-saito@guitar.ocn.ne.jp> wrote: >> Please correct one mistake of mine...sorry. >> This patch solved problem of win32.:-) > > You mean the += -lws2_32 must be after PGXS? Ok, but moving > the PGXS line is not right as it should after all variables > are set. I moved the SHLIB_LINK += line instead. > > Please test. > > -- > marko > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Andrew Dunstan
Date:
Asko Oja wrote: > > About citext. Skype is using various hacks and workarounds because > there was no such type in PostgreSQL and i understand others also. To > me it seems to be choice between couple of developers doing it once > and for all and hundreds of developers inventing the wheel every day > and not to mention hours spent debugging over various layers of > applications. It just shows how hackers have totally different point > of view on things from people who are using the program:) But again i > am just a manager and should be lower than grass in hackers list :) > > Plenty of us who are hackers are also users. ISTM that Tom's objection is really that citext is a hack, and that it will actually make it harder for us to get to a collation-based case insensitive comparison. I think if we adopt that view then we need to form a plan for doing this right, and soon, as it is a significant current pain point, especially for people migrating from other databases. cheers andrew
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"Marko Kreen"
Date:
On 7/28/08, Asko Oja <ascoja@gmail.com> wrote: > Would capability to do remote procedure calls useful addition to PostgreSQL > feature set? I agree with Tom/Simon on the topic of builtin remote calls - if there is a plan to implement CREATE REMOTE TABLE/VIEW (builtin remote views) then it should be quite easy to extend the implementation to functions: CREATE REMOTE FUNCTION. Thus making the PL version of remote calls redundant. Although that seems a far way off. Btw, one thing that could be immediately useful would be to extract the connection defining part from SQL-MED and add that to core, so that dblink, plproxy and dbi-link could share that. But that needs someone who has ability to process a 500+ page standard. -- marko
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"David E. Wheeler"
Date:
On Jul 28, 2008, at 09:01, Andrew Dunstan wrote: > Plenty of us who are hackers are also users. > > ISTM that Tom's objection is really that citext is a hack, and that > it will actually make it harder for us to get to a collation-based > case insensitive comparison. Well, that's why it's in contrib. > I think if we adopt that view then we need to form a plan for doing > this right, and soon, as it is a significant current pain point, > especially for people migrating from other databases. +1 Best, David
Andrew Dunstan <andrew@dunslane.net> writes: > ISTM that Tom's objection is really that citext is a hack, and that it > will actually make it harder for us to get to a collation-based case > insensitive comparison. Well, it won't make it harder to implement collations; but I worry that people who have been relying on the citext syntax will have a hard time migrating to collations. Perhaps if someone did the legwork to determine exactly what that conversion would look like, it would assuage the fear. regards, tom lane
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Andrew Dunstan
Date:
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > >> ISTM that Tom's objection is really that citext is a hack, and that it >> will actually make it harder for us to get to a collation-based case >> insensitive comparison. >> > > Well, it won't make it harder to implement collations; but I worry that > people who have been relying on the citext syntax will have a hard time > migrating to collations. Perhaps if someone did the legwork to > determine exactly what that conversion would look like, it would assuage > the fear. > > I kind of assumed we would do it by implementing the COLLATE clause of the CREATE DOMAIN statement. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes: > Tom Lane wrote: >> Well, it won't make it harder to implement collations; but I worry that >> people who have been relying on the citext syntax will have a hard time >> migrating to collations. Perhaps if someone did the legwork to >> determine exactly what that conversion would look like, it would assuage >> the fear. > I kind of assumed we would do it by implementing the COLLATE clause of > the CREATE DOMAIN statement. But to define such a domain, you'd have to commit to a case-insensitive version of a specific collation, no? citext currently means "case insensitive version of whatever the database's default collation is". This might be worrying over nothing significant, but I'm not convinced... regards, tom lane
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Andrew Dunstan
Date:
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > >> Tom Lane wrote: >> >>> Well, it won't make it harder to implement collations; but I worry that >>> people who have been relying on the citext syntax will have a hard time >>> migrating to collations. Perhaps if someone did the legwork to >>> determine exactly what that conversion would look like, it would assuage >>> the fear. >>> > > >> I kind of assumed we would do it by implementing the COLLATE clause of >> the CREATE DOMAIN statement. >> > > But to define such a domain, you'd have to commit to a case-insensitive > version of a specific collation, no? citext currently means "case > insensitive version of whatever the database's default collation is". > This might be worrying over nothing significant, but I'm not > convinced... > > > Well, that's all we've got right now. Presumably as David says we could leave citext sitting in contrib for compatibility reasons, once we get more fine-grained collation support. I guess, too, we can add all sorts of warnings about citext not being future-proof. cheers andrew
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Martijn van Oosterhout
Date:
On Mon, Jul 28, 2008 at 03:49:21PM -0400, Tom Lane wrote: > > I kind of assumed we would do it by implementing the COLLATE clause of > > the CREATE DOMAIN statement. > > But to define such a domain, you'd have to commit to a case-insensitive > version of a specific collation, no? citext currently means "case > insensitive version of whatever the database's default collation is". > This might be worrying over nothing significant, but I'm not > convinced... In the version of COLLATE I did you had variations on locales (asc/desc, case (in)sensetive) which could be selected. So you could make COLLATE CASE_INSENSITIVE actually just modify the existing collation. That said, this is no more of a deal than that text also has a default collation. You talk about "the database's default collation" but with proper collation support that statement is meaningless. A database has no collation, only types, expressions and columns do. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines.
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"Dawid Kuroczko"
Date:
On Mon, Jul 21, 2008 at 9:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Comments? Tough question. First PL/Proxy. One objection against PL/Proxy is that it might interfere with SQL-MED implementation. I don't think its the case because both solve slightly different problems. SQL-MED brings remote tables "local" (importing whole schemas and such). PL/Proxy allows remote calls and load balancing/distribution. I think it might be even valuable to use these two together (building on strengths of these two). By the way, while reading SQL-MED standard I didn't find obvious way of calling ad-hoc remote tables (as in Oracle's db links for instance), only either creating remote tables or running in "passthrough" mode. I guess I did miss something, I was only skimming through it. As for citext I am less enthusiastic. While I understand the need for case insensitivity, it feels hacky. Like something which screams to be more general but fails to do so. And if citext, how about say rawtext (locale-less text)? [1] utf8text (utf8 compilant text available even if POSIX localle is used) and so on. ;) I would still want citext to get into contrib, but my heart is strongest with PL/Proxy here. Regards, Dawid [1]: Actually I think it would be better to "upgrade" bytea into something like locale-less, 8-byte, raw-text-alike. I mean, be able to do regex queries, LIKE queries, etc on it. I sometimes miss that kind of functionality. -- .................. ``The essence of real creativity is a certain: *Dawid Kuroczko* : playfulness, a flitting from ideato idea: qnex42@gmail.com : without getting bogged down by fixated demands.''`..................' Sherkaner Underhill,A Deepness in the Sky, V. Vinge
Martijn van Oosterhout <kleptog@svana.org> writes: > That said, this is no more of a deal than that text also has a default > collation. You talk about "the database's default collation" but with > proper collation support that statement is meaningless. Well, we had better still be able to support the concept, or a lot of applications that work fine today will fail. regards, tom lane
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"David E. Wheeler"
Date:
On Jul 28, 2008, at 12:29, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> ISTM that Tom's objection is really that citext is a hack, and that >> it >> will actually make it harder for us to get to a collation-based case >> insensitive comparison. > > Well, it won't make it harder to implement collations; but I worry > that > people who have been relying on the citext syntax will have a hard > time > migrating to collations. Perhaps if someone did the legwork to > determine exactly what that conversion would look like, it would > assuage > the fear. Well, there is no syntax for citext. Right now, lots of folks are using LOWER() all over the place, in indexes and queries, to get the behavior implemented by citext, and that will be a *lot* harder to migrate from than citext will be. To upgrade from citext, I expect that what one will have to do is to alter the column to change its data type from citext to TEXT + collation. Am I missing something here? Thanks, David
"David E. Wheeler" <david@kineticode.com> writes: > To upgrade from citext, I expect > that what one will have to do is to alter the column to change its > data type from citext to TEXT + collation. What I'm wondering is how closely that will match the semantics of the contrib module ... regards, tom lane
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Peter Eisentraut
Date:
Am Monday, 28. July 2008 schrieb Tom Lane: > But to define such a domain, you'd have to commit to a case-insensitive > version of a specific collation, no? citext currently means "case > insensitive version of whatever the database's default collation is". So in the future, someone using citext with lc_collate = en_US attempting to upgrade would then define CREATE DOMAIN citext AS text COLLATION "en_US@ci" And yes, you would potentially have different definitions of this citext domain in different database clusters, depending on what configuration you are upgrading from, but I don't see that as a problem. It is the natural thing to do.
Peter Eisentraut <peter_e@gmx.net> writes: > Am Monday, 28. July 2008 schrieb Tom Lane: >> But to define such a domain, you'd have to commit to a case-insensitive >> version of a specific collation, no? �citext currently means "case >> insensitive version of whatever the database's default collation is". > So in the future, someone using citext with lc_collate = en_US attempting to > upgrade would then define > CREATE DOMAIN citext AS text COLLATION "en_US@ci" > And yes, you would potentially have different definitions of this citext > domain in different database clusters, depending on what configuration you > are upgrading from, but I don't see that as a problem. It is the natural > thing to do. I'm still not completely convinced that this would be smooth in practice; for instance there might be situations where you wanted to define citext but didn't know the target database collation. Still, I have to concede that it's probably an adequate answer, or at least close enough that the objection to including citext now doesn't hold up. It seems that the majority opinion is in favor of including citext in contrib, so I will go work on that now. regards, tom lane
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"David E. Wheeler"
Date:
On Jul 28, 2008, at 18:31, Tom Lane wrote: >> To upgrade from citext, I expect >> that what one will have to do is to alter the column to change its >> data type from citext to TEXT + collation. > > What I'm wondering is how closely that will match the semantics of the > contrib module ... By "semantics" do you mean behavior, in terms of how closely operator comparisons will return the same results? I have no idea, personally, but it's no worse then TEXT, is it? The use of TEXT and LOWER() being what people are doing now? Best, David
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"David E. Wheeler"
Date:
On Jul 29, 2008, at 08:58, Tom Lane wrote: > It seems that the majority opinion is in favor of including citext > in contrib, so I will go work on that now. Damn, I was away from mail yesterday; sorry. I have some revisions, mostly improving casting compatibility with text. Tom, have you committed anything yet? Shall I pull my improved patch together and send it today (I was still writing tests and tweaking things to get the casts right…). Thanks, David
"David E. Wheeler" <david@kineticode.com> writes: > Damn, I was away from mail yesterday; sorry. I have some revisions, > mostly improving casting compatibility with text. Huh? What's to improve? I know that you're still fooling with the regexp functions, but I figured that could be added later. > Tom, have you committed anything yet? No, but I've put a couple of hours into editorialization and don't want to throw that away. How about you wait for my commit and then send a patch revising whatever you want to? regards, tom lane
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
"David E. Wheeler"
Date:
On Jul 29, 2008, at 11:01, Tom Lane wrote: > "David E. Wheeler" <david@kineticode.com> writes: >> Damn, I was away from mail yesterday; sorry. I have some revisions, >> mostly improving casting compatibility with text. > > Huh? What's to improve? > > I know that you're still fooling with the regexp functions, but I > figured that could be added later. > >> Tom, have you committed anything yet? > > No, but I've put a couple of hours into editorialization and don't > want to throw that away. How about you wait for my commit and then > send a patch revising whatever you want to? Sure. It's mostly just additional casts and tests. I'd be happy to integrate it into your commit. Thanks, David
"David E. Wheeler" <david@kineticode.com> writes: > Sure. It's mostly just additional casts and tests. I'd be happy to > integrate it into your commit. Okay, it's committed with minor revisions --- the biggest thing I fixed was the lack of an uninstall script. I saw what you were talking about in terms of still having some casting issues: having to put in a quote_literal(citext) alias function seems like a huge hack, and I notice that cases like contrib_regression=# select 'a'::text || 'b'::citext; ERROR: operator is not unique: text || citext still don't work even though you put in an alias || operator. It seems to me that trying to fix these things retail is a losing proposition. The reason you need these, instead of having everything "just work" like varchar does, is that citext isn't seen as a member of the string type category, and so the "preferred type" preference for text isn't applied. What we ought to do about that IMHO is make a way for user-defined types to declare what category they belong to. This has been foreseen as needed for a *very* long time, but we never really had a forcing function to make us do it before. Obviously the solution should involve a new column in pg_type and a new type property in CREATE TYPE, but what should the representation be? A full-on approach would make the type categories be real SQL objects with their own system catalog and reference them by OID, but I can't help thinking that that's overkill. Anyway, debating that is probably material for a separate thread ... regards, tom lane
Re: Do we really want to migrate plproxy and citext into PG core distribution?
From
Zdenek Kotala
Date:
Tom Lane napsal(a): > > Obviously the solution should involve a new column in pg_type and > a new type property in CREATE TYPE, but what should the representation > be? A full-on approach would make the type categories be real SQL > objects with their own system catalog and reference them by OID, > but I can't help thinking that that's overkill. > > Anyway, debating that is probably material for a separate thread ... The collation support also needs to determine which data type is text/string. Zdenek -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql