Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 [EMAIL PROTECTED] 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
Peter Eisentraut [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
David E. Wheeler [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
On Jul 29, 2008, at 11:01, Tom Lane wrote: David E. Wheeler [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
David E. Wheeler [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
Hi hackers Just my non hacker view on the pl/proxy matter. From FAQ: PL/Proxy is compact language for remote calls between PostgreSQL databases. Why we submitted pl/proxy into core at all? 1. Current core distribution contains dblink which sucks both usability wise and security wise but being part of core distribution will be first thing people are going to try out. We wanted to save people losing couple of days trying out dblink before looking for other alternatives like it happend with us. 2. Various languages are part of core distribution and pl/proxy by adding possibility to call remotely procedures created with these languages seems to be logical extension to PostgreSQL in general. And it makes it essential for pl/proxy to stay compatible with all the developments in function calling syntax. 3. And last but not least to make it easier to use for whoever who might need to do remote procedure calls between PostgreSQL servers. So i rephrase your question: Would capability to do remote procedure calls useful addition to PostgreSQL feature set? In my experience when organization grows out of one database on one server remote calls are needed quite soon. 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 :) regards. Asko skype: askoja PS: I am sorry for this reply coming so late didn't want to spoil my vacation :) On Mon, Jul 21, 2008 at 10:43 PM, Tom Lane [EMAIL PROTECTED] 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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
On 7/28/08, Asko Oja [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
Andrew Dunstan [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
Andrew Dunstan [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 [EMAIL PROTECTED] http://svana.org/kleptog/ Please line up in a tree and maintain the heap invariant while boarding. Thank you for flying nlogn airlines. signature.asc Description: Digital signature
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
On Mon, Jul 21, 2008 at 9:43 PM, Tom Lane [EMAIL PROTECTED] 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 idea to idea : [EMAIL PROTECTED] : without getting bogged down by fixated demands.'' `..' Sherkaner Underhill, A Deepness in the Sky, V. Vinge -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
Martijn van Oosterhout [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
On Jul 28, 2008, at 12:29, Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
David E. Wheeler [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 On Fri, Jul 25, 2008 at 2:19 AM, Tom Lane [EMAIL PROTECTED] wrote: Robert Haas [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
Alvaro Herrera [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
Tom Lane wrote: Hannu Krosing [EMAIL PROTECTED] 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
Ron Mayer [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
On 7/24/08, Peter Eisentraut [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
On Wed, 2008-07-23 at 12:38 -0400, Tom Lane wrote: Greg Sabino Mullane [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
Hannu Krosing [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
On Thu, Jul 24, 2008 at 4:37 PM, Tom Lane [EMAIL PROTECTED] wrote: Hannu Krosing [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
Robert Haas [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
On Thu, Jul 24, 2008 at 2:37 PM, Tom Lane [EMAIL PROTECTED] wrote: Hannu Krosing [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
-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 [EMAIL PROTECTED] PGP Key: 0x14964AC8 200807231145 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkiHUlgACgkQvJuQZxSWSshURACg2MIfdH0cJOTf75HmuGEzlxo6 OBQAn21sqZ+rBEel1cf2dAIYpoWPHwW5 =Pj7J -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
Greg Sabino Mullane [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
Tom Lane wrote: Greg Sabino Mullane [EMAIL PROTECTED] 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
On 7/23/08, Greg Sabino Mullane [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
-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 prefix citext 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- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
Tom Lane [EMAIL PROTECTED] 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! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
On Tue, Jul 22, 2008 at 2:39 PM, Gregory Stark [EMAIL PROTECTED] wrote: Tom Lane [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
Dave Page [EMAIL PROTECTED] writes: On Tue, Jul 22, 2008 at 2:39 PM, Gregory Stark [EMAIL PROTECTED] wrote: Tom Lane [EMAIL PROTECTED] 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! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
Simon Riggs [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
Josh Berkus [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
On Tue, 2008-07-22 at 17:36 -0400, Tom Lane wrote: Josh Berkus [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
Joshua D. Drake [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
On Tue, 2008-07-22 at 17:54 -0400, Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
Joshua D. Drake [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
On Tue, 2008-07-22 at 23:29 -0400, Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
Joshua D. Drake [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
On Wed, 2008-07-23 at 00:01 -0400, Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
Josh Berkus [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext into PG core distribution?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
