Thread: plPHP and plRuby
Hello, We were going to submit plPHP to core for inclusion but it is not ready yet. Namely it requires the apache SAPI which could introduce some portability issues. The other issues it has (such as some array parsing problems) are minor and could probably be fixed easily within the beta period but the SAPI is a show stopper. As some of you know, we have also procured permission to relicense plRuby so that the project can include it in core. I have a version that works with -HEAD. However plRuby is even a stranger beast as it uses an entirely ruby build system. I am also fairly confident that it does not meat the PostgreSQL style guidelines. Is there enough interest in plRuby to get it where it needs to be for possible inclusion into core? Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Sun, 16 Jul 2006, Joshua D. Drake wrote: > Hello, > > However plRuby is even a stranger beast as it uses an entirely ruby > build system. I am also fairly confident that it does not meat the > PostgreSQL style guidelines. Well... JDBC used its own. > > Is there enough interest in plRuby to get it where it needs to be for > possible inclusion into core? I'd like to see it ship with the core distribution. Thanks, Gavin
Am Montag, 17. Juli 2006 03:18 schrieb Joshua D. Drake: > We were going to submit plPHP to core for inclusion but it is not ready > yet. > Is there enough interest in plRuby to get it where it needs to be for > possible inclusion into core? Considering that PL/Java effectively just got shot down, I don't see any hope for these. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: >Am Montag, 17. Juli 2006 03:18 schrieb Joshua D. Drake: > > >>We were going to submit plPHP to core for inclusion but it is not ready >>yet. >> >> > > > >>Is there enough interest in plRuby to get it where it needs to be for >>possible inclusion into core? >> >> > >Considering that PL/Java effectively just got shot down, I don't see any hope >for these. > > > But the reasons that applied to PL/Java (masses of non-C code was the main one) probably don't apply in these 2 cases. cheers andrew
Peter Eisentraut wrote: > Am Montag, 17. Juli 2006 03:18 schrieb Joshua D. Drake: >> We were going to submit plPHP to core for inclusion but it is not ready >> yet. > >> Is there enough interest in plRuby to get it where it needs to be for >> possible inclusion into core? > > Considering that PL/Java effectively just got shot down, I don't see any hope > for these. PLRuby is written in C. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Andrew Dunstan wrote: > But the reasons that applied to PL/Java (masses of non-C code was the > main one) probably don't apply in these 2 cases. I don't think it's the amount of non-C code; it's the amount of code that no one understands. Plus, an argument *for* inclusion was build farm coverage, which I understand will be solved in a different way, applicable to all external modules. Another argument was buzzword compliance, which doesn't apply to these two new candidates. So in summary, while I have not seen any valid reason for these inclusions, there continue to be some against it. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Joshua D. Drake wrote: > PLRuby is written in C. Specifically on the matter of PL/Ruby -- and if you're trying to be such an advocate about it, you should at least spell it right -- I have never seen the author particularly active within this community, so I have my doubts whether the development processes will integrate well. In fact, shouldn't the inclusion request come from the author in the first place? -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > Andrew Dunstan wrote: >> But the reasons that applied to PL/Java (masses of non-C code was the >> main one) probably don't apply in these 2 cases. > > I don't think it's the amount of non-C code; it's the amount of code > that no one understands. Plus, an argument *for* inclusion was build > farm coverage, which I understand will be solved in a different way, > applicable to all external modules. Another argument was buzzword > compliance, which doesn't apply to these two new candidates. So in > summary, while I have not seen any valid reason for these inclusions, > there continue to be some against it. Ahh o.k. not to be argumentative but PHP is huge and RUby gets more then it fair share of press and articles written about it now. Alot of those *enterprises* that used to use Java are migrating to PHP (why I really don't know but that isn't the point). That being said, PLphp is currently a no-op and won't be able to be considered for 8.2 due to portability issues. However PLruby is a valid inclusion and would enhance our portfolio of pl languages nicely. PLruby also has the benefit of not being repulsive to Perl or Python programmers (where is many perl and python guys really don't like the other ;)). Sincerely, Joshua D. Drake > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Peter Eisentraut wrote: > Joshua D. Drake wrote: >> PLRuby is written in C. > > Specifically on the matter of PL/Ruby -- and if you're trying to be such > an advocate about it, you should at least spell it right -- I have > never seen the author particularly active within this community, so I > have my doubts whether the development processes will integrate well. > In fact, shouldn't the inclusion request come from the author in the > first place? That is a good point. However in this case, it was CMD that worked with the Author to change the license, specifically for this case. I don't think the author really had any intent of submitting it until we approached him. From a personal perspective, I do not care if we include PL/Ruby. I don't use Ruby. I am a Python guy. However I know a lot of Ruby folk that use PostgreSQL. This would be a good way to improve the native Ruby support for PostgreSQL. Sincerely, Joshua D. Drake > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Peter Eisentraut wrote:
>Andrew Dunstan wrote:
>
>
>>But the reasons that applied to PL/Java (masses of non-C code was the
>>main one) probably don't apply in these 2 cases.
>>
>>
>
>I don't think it's the amount of non-C code; it's the amount of code
>that no one understands. Plus, an argument *for* inclusion was build
>farm coverage, which I understand will be solved in a different way,
>applicable to all external modules. Another argument was buzzword
>compliance, which doesn't apply to these two new candidates. So in
>summary, while I have not seen any valid reason for these inclusions,
>there continue to be some against it.
>
>
>
Well, I am not making any promises right now about when buildfarm will
support external modules.
My current thinking goes something like this:
. the config file will contain an extra stanza looking something like this: addons => { <addonname> => { cvsrepo =>
"<repolocn>", module=>
"<modulename>" } ... }
. addons will be checked out at the same time as the core, but into a
separate directory. We will check them for recent mods in the same way
as the core.
. after we run "make installcheck" for the core we will run "make" for
each addon using the installed pgxs.
. after we run "make installcheck" for contrib we will run "make
installcheck" for each addon.
(Question - do we restrict addons to those that will build using pgxs?)
Happily, most of the webapp is agnostic about what is reported on -
probably adding one db field containing the addon names for the build
would suffice.
There are some odd wrinkles. For instance, construction of the URLs for
changed files will be somewhat harder. For that reason I think I am
going to insist at least in the first instance that all addons must be
hosted on pgfoundry where we know perfectly well how to construct cvsweb
URLs.There will undoubtedly be more when I get down to it. And we might
need to ignore addons for builds on stable branches up to and including
8.2 - I don't know yet.
Now, if someone feels like taking those ideas and running with them in
the buildfarm client code they are welcome to drop me a line and I can
add them to the project as a developer. Otherwise it will have to wait
till I get around to it. That's likely to be some way well into the 8.3
development cycle at the earliest.
And lastly, if we are not going to include these in core, I repeat what
I said before: we need to undertake some *serious* evangelising to major
packagers to get them to build more than just the core among their
standard packages.
cheers
andrew
> > And lastly, if we are not going to include these in core, I repeat what > I said before: we need to undertake some *serious* evangelising to major > packagers to get them to build more than just the core among their > standard packages. Andrew I keep seeing this, but what major packagers are we talking about? Actually as I look at this, the only major distribution (that is not commercial) that doesn't support a lot of PostgreSQL packages is Fedora. Ubuntu Debian Gentoo FreeBSD All have a ton of packages (including plruby). Sincerely, Joshua D. Drake > > cheers > > andrew > > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Peter, > I don't think it's the amount of non-C code; it's the amount of code > that no one understands. Plus, an argument *for* inclusion was build > farm coverage, which I understand will be solved in a different way, > applicable to all external modules. Another argument was buzzword > compliance, which doesn't apply to these two new candidates. So in > summary, while I have not seen any valid reason for these inclusions, > there continue to be some against it. The main reason for including PL/Ruby is that by whatever accident the Ruby community is tending to choose PostgreSQL as their SQL-RDBMS of choice. This is a tendency we'd like to encourage, and one way to do so is to attract Ruby developers to the idea of putting Ruby logic into the database. This also might have the effect of getting more Rails developers to learn about real database architecture. Secondly, I've been told Ruby has some nice features as a language that make it a useful edition to our "stable" of procedural languages. Hopefully the Ruby aficiandos will speak up an enumerate these. On the other hand, if we include PL/Perl, Tcl and Python but exclude Ruby from the main package we are effectively making a statement to Ruby users that their language is inferior in our consideration. And, as Andrew said, Buildfarm External Modules are not going to be added next month. However, the lack of a maintainer who is an active participant in the community is a serious drawback ... probably even a fatal one. Josh, is there a reason why the PL/Ruby hacker doesn't want to play with us? -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco
> > However, the lack of a maintainer who is an active participant in the > community is a serious drawback ... probably even a fatal one. Josh, is > there a reason why the PL/Ruby hacker doesn't want to play with us? I don't think it is, "doesn't want to play with us". I think he just doesn't :). That being said, we may want to check and see if he participates in PostgreSQLFR (he is french). Also note, that if it were included, CMD would dedicate resources to help keeping it stable etc... Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Mon, 2006-07-17 at 10:11 -0700, Josh Berkus wrote: > On the other hand, if we include PL/Perl, Tcl and Python but exclude Ruby > from the main package we are effectively making a statement to Ruby users > that their language is inferior in our consideration. Hardly -- no more so than not including JDBC and PL/Java in the main CVS is evidence that we're all Java haters. The fact that we include PL/Perl, PL/Python and PL/Tcl is more a matter of momentum/historical accident than an expression of preference, IMHO. > However, the lack of a maintainer who is an active participant in the > community is a serious drawback Well, if the author is interested in maintaining PL/Ruby as part of the postgresql.org CVS tree (is he?), I think that is sufficient. Whether he "participates in the community" beyond maintaining PL/Ruby is not really relevant, IMHO. (FWIW, I'd be fairly comfortable hacking on PL/Ruby, as I have some prior experience with Ruby and its C API.) -Neil
Neil, > (FWIW, I'd be fairly comfortable hacking on PL/Ruby, as I have some > prior experience with Ruby and its C API.) Well, if you're willing to be a maintainer, that removes a major roadblock. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco
On Mon, Jul 17, 2006 at 12:18:46PM -0400, Andrew Dunstan wrote: > Well, I am not making any promises right now about when buildfarm will > support external modules. I've been playing with the idea of having a subdirectory named "extras" with descriptor files describing how to fetch a project and compile it. I got the fetching and the unpacking going, but the building isn't there yet. Still, it's an interesting idea... > And lastly, if we are not going to include these in core, I repeat what > I said before: we need to undertake some *serious* evangelising to major > packagers to get them to build more than just the core among their > standard packages. Ack. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Ühel kenal päeval, E, 2006-07-17 kell 22:01, kirjutas Martijn van Oosterhout: > On Mon, Jul 17, 2006 at 12:18:46PM -0400, Andrew Dunstan wrote: > > Well, I am not making any promises right now about when buildfarm will > > support external modules. > > I've been playing with the idea of having a subdirectory named "extras" > with descriptor files describing how to fetch a project and compile it. > I got the fetching and the unpacking going, but the building isn't > there yet. Still, it's an interesting idea... Actually it would be nice to have the not-included PLs present in src/pl/ as their own directories with a README.TXT containing fetch and build instructions So we would have src/pl/plphp/README.TXT src/pl/pljava/README.TXT src/pl/plj/README.TXT and anybody looking for pl-s would find the info in a logical place -- ---------------- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com
On Mon, 17 Jul 2006, Andrew Dunstan wrote: > And lastly, if we are not going to include these in core, I repeat what > I said before: we need to undertake some *serious* evangelising to major > packagers to get them to build more than just the core among their > standard packages. Just because an addon is in core (or not) doesn't mean that the packager responsible for building a package for 'the rdbms' is going to bother going into the contrib directory, or any other, to build 'extra stuff' ... In fact, with all of the ppl that lurk on these lists, aren't there enough here that could learn to package for their respective OSs and submit those for inclusion? Or, at least, mentor the various projects maintainers into how to build a package? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Tue, 18 Jul 2006, Hannu Krosing wrote: > Ühel kenal päeval, E, 2006-07-17 kell 22:01, kirjutas Martijn van > Oosterhout: >> On Mon, Jul 17, 2006 at 12:18:46PM -0400, Andrew Dunstan wrote: >>> Well, I am not making any promises right now about when buildfarm will >>> support external modules. >> >> I've been playing with the idea of having a subdirectory named "extras" >> with descriptor files describing how to fetch a project and compile it. >> I got the fetching and the unpacking going, but the building isn't >> there yet. Still, it's an interesting idea... > > Actually it would be nice to have the not-included PLs present in > src/pl/ as their own directories with a README.TXT containing fetch and > build instructions > > So we would have > > src/pl/plphp/README.TXT > src/pl/pljava/README.TXT > src/pl/plj/README.TXT > > and anybody looking for pl-s would find the info in a logical place *That* idea I like ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Marc G. Fournier wrote: >> Actually it would be nice to have the not-included PLs present in >> src/pl/ as their own directories with a README.TXT containing fetch and >> build instructions >> >> So we would have >> >> src/pl/plphp/README.TXT >> src/pl/pljava/README.TXT >> src/pl/plj/README.TXT >> >> and anybody looking for pl-s would find the info in a logical place > > *That* idea I like ... > ISTM that a clear strategy for how to deal with core, contrib, add-ons, etc. is long overdue and that's the reason why these discussions pop up over and over again. The question "What are the criterion's for core inclusion?" has not yet been answered. I though PL/Java fulfilled those criterion's but a new threshold for the #lines of code and a concern for code in unmaintainable language made it impossible. The result of an unclear strategy can be perceived as somewhat unjust. There seem to be a very unanimous consensus that PL/pgsql belongs in core. Large object support, free text search and some others also receive support by everyone. These add-ons clearly belong where they are. The "historical reasons" to continuously include others are, IMHO, not so obvious and the result undoubtedly creates first- and second class citizens in the module flora. The split doesn't correlate very well with feature richness or popularity. I have a suggestion that might help clearing things up a bit :-) A couple of specialized teams need to be established (or rather, formalized since they already exists to some extent) that can be thought of as "core subsidiary's". The idea is that such a team would take on the maintenance of one specialized area of PostgreSQL. Java, for instance, is such an area. PostgreSQL has a huge number of Java users. They all use the JDBC driver and a few use PL/Java. There's been talk about Eclipse tool support and some will have an interest in XA-compliance in order to gain JTA support, etc. Today, it's scattered all over the place. Other subsidiary teams should be formed around odbc (or .net perhaps), php, ruby, replication/clustering, etc. to take control over those areas. A very important part of my suggestion is that for the normal user, it would appear that what a "core subsidiary" team contribute really is *part of* the database proper and not something maintained by a third-party contributor or commercial vendor. The team would maintain their own website (although all layout would be centralized), source code control system, mailing list etc. but they would share a lot more of the PostgreSQL infrastructure then what is shared today. Important things would be: - Documentation. Inclusion of a subsidiary module should mean that some chapters are added (automatically) to the user manual. - Build farm support. - Packaging and downloads - Server infrastructure - Seamless navigation from the PostgreSQL main web-site. PgFoundry would live on like today, targeted on third-party modules and serving as an incubator for modules that aim to be included in core or into one of its subsidiaries. Kind Regards, Thomas Hallgren
On Mon, Jul 17, 2006 at 07:37:41PM -0300, Marc G. Fournier wrote: > >Actually it would be nice to have the not-included PLs present in > >src/pl/ as their own directories with a README.TXT containing fetch and > >build instructions > > > >So we would have > > > >src/pl/plphp/README.TXT > >src/pl/pljava/README.TXT > >src/pl/plj/README.TXT > > > >and anybody looking for pl-s would find the info in a logical place > > *That* idea I like ... You could take the idea even further and place Makefiles or scripts there to download to source and set it up for compiling. "make cvs" or some such. Then on a stable release the script gets updated with the appropriate CVS tag and you're done. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
On 17-Jul-06, at 6:37 PM, Marc G. Fournier wrote: > On Tue, 18 Jul 2006, Hannu Krosing wrote: > >> Ühel kenal päeval, E, 2006-07-17 kell 22:01, kirjutas Martijn van >> Oosterhout: >>> On Mon, Jul 17, 2006 at 12:18:46PM -0400, Andrew Dunstan wrote: >>>> Well, I am not making any promises right now about when >>>> buildfarm will >>>> support external modules. >>> >>> I've been playing with the idea of having a subdirectory named >>> "extras" >>> with descriptor files describing how to fetch a project and >>> compile it. >>> I got the fetching and the unpacking going, but the building isn't >>> there yet. Still, it's an interesting idea... >> >> Actually it would be nice to have the not-included PLs present in >> src/pl/ as their own directories with a README.TXT containing >> fetch and >> build instructions >> >> So we would have >> >> src/pl/plphp/README.TXT >> src/pl/pljava/README.TXT >> src/pl/plj/README.TXT >> >> and anybody looking for pl-s would find the info in a logical place > > *That* idea I like ... Actually taking that one step further. At least two or three of these projects have automated build processes (Ruby and Java, and I believe Python), placing their equivalent of Makefile into this dir would allow users versed in the language of choice to build their extension easily. > > ---- > Marc G. Fournier Hub.Org Networking Services (http:// > www.hub.org) > Email . scrappy@hub.org MSN . > scrappy@hub.org > Yahoo . yscrappy Skype: hub.org ICQ . 7615664 > ---------------------------(end of > broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that > your > message can get through to the mailing list cleanly >
Marc G. Fournier wrote: > > src/pl/plphp/README.TXT > > src/pl/pljava/README.TXT > > src/pl/plj/README.TXT > > > > and anybody looking for pl-s would find the info in a logical place > > *That* idea I like ... Why don't we just reorganize our tree like that: everything/databases/postgresql/src/... everything/databases/mysql/README.txt everything/kernels/freebsd/README.txt everything/kernels/linux/README.txt ... That will make it much easier for people to set up their systems. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Hannu Krosing wrote: > So we would have > > src/pl/plphp/README.TXT > src/pl/pljava/README.TXT > src/pl/plj/README.TXT > > and anybody looking for pl-s would find the info in a logical place Right. When was the last time any user looked under src/pl in the first place? Or even under src? If you're looking for pljava, it's the first hit in Google. I think people need to relax more. We are not making statements about language preferences -- making that claim is just paranoia. We are not missing the enterprise train, and there might be just as many people moving from PHP to Java, or we might just be making this up because no one can count that anyway. And we are not going to educate any Rail users, because people don't like to be lectured to if they didn't ask for it. The organization of the source code is controlled by exactly two factors: 1. history 2. convenience of development Anything else is between you and your packager. And if that didn't convince you, I still got PL/sh in the wait ... -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut <peter_e@gmx.net> writes:
> And if that didn't convince you, I still got PL/sh in the wait ...
It seems like there may be enough interest in PL/Ruby to justify
including it in our distro, but after taking a look at the package
I can see a couple of pretty serious objections:
1. Wrong license. Unless the author can be persuaded to relicense as
straight BSD, this discussion is a waste of time.
2. Coding style. The man does not believe in comments; do we really
think anyone else is going to be able to maintain his work?
regards, tom lane
Peter Eisentraut wrote: > Hannu Krosing wrote: >> So we would have >> src/pl/pljava/README.TXT >> >> and anybody looking for pl-s would find the info in a logical place > > Right. When was the last time any user looked under src/pl in the first > place? Or even under src? If you're looking for pljava, it's the > first hit in Google. The difference is that I will have reasonable confidence that the README.TXT under "src/pl" will give instructions that match the version of PostgreSQL that I have. I assume that README will call out the version of PL/R or PL/Ruby that I want that was tested with the release of PostgreSQL I have. The first hit on Google will probably give me the most recently blogged about version; which does nothing to help me find what I need. > The organization of the source code is controlled by exactly two > factors: > 2. convenience of development I thought "convenience of development" included the addressing the problem that PLs are annoyingly deeply tied to specific versions of Core. I would imagine with this README.TXT proposal, it's the responsibility of the PL/XXX developer to port their PL to PostgreSQL during the Beta, and if the did and tested it, the release will point to the version of the PL supported by the PL maintainer for that version. If they don't do this testing during the beta, the README.TXT may merely say the "PL/Haskell team did not complete testing during the 8.2 beta; so good luck". This aids to the convenience of development of PostgreSQL and the PLs because it defines the process and responsibility for integration testing the PLs with the Core releases; and puts some pressure to synchronize the releases. > Anything else is between you and your packager. > > And if that didn't convince you, I still got PL/sh in the wait ... With which versions of PostgreSQL is this version of PL/sh supported? I see that PL/sh on http://pgfoundry.org/projects/plsh/ is version 1.1? Does that mean it goes with PostgreSQL 1.1? The Projects page for PL/SH (http://plsh.projects.postgresql.org/) suggests it was last modified in May 2005 - does that mean I need the May 2005 backend of PostgreSQL to compile it? Oh. The download page says older releases are also supported. Does that include 7.1? Putting this info in the README.TXT is one way to help users know what's supported. If I saw a README.TXT for pl/sh I'd have some confidence I'd be directly pointed to the version I need.
Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
> Peter Eisentraut wrote:
>> Right. When was the last time any user looked under src/pl in the first
>> place? Or even under src? If you're looking for pljava, it's the
>> first hit in Google.
> The difference is that I will have reasonable confidence that
> the README.TXT under "src/pl" will give instructions that match
> the version of PostgreSQL that I have. I assume that README
> will call out the version of PL/R or PL/Ruby that I want that
> was tested with the release of PostgreSQL I have.
On what do you base that assumption? A README file laying about in an
otherwise unused part of the source tree is the very definition of "out
of sight, out of mind". I can pretty much guarantee you that it will
NOT get updated, especially not during minor releases. Even if it is up
to date at the instant we put out a release, it'll be obsolete as soon
as the external project makes an update release. ISTM links like this
are far better kept on project websites ...
> I would imagine with this README.TXT proposal, it's the responsibility
> of the PL/XXX developer to port their PL to PostgreSQL during the Beta,
> and if the did and tested it, the release will point to the version
> of the PL supported by the PL maintainer for that version.
And if they didn't? I was just noticing that the current release of
plruby contains installation instructions that appear to date to 7.3.
If he can't be bothered to update his own docs, what are the odds that
he'll submit timely updates for a README in the main source tree?
regards, tom lane
Tom Lane wrote: >> The difference is that I will have reasonable confidence that >> the README.TXT under "src/pl" will give instructions that match >> the version of PostgreSQL that I have. I assume that README >> will call out the version of PL/R or PL/Ruby that I want that >> was tested with the release of PostgreSQL I have. > > On what do you base that assumption? A README file laying about in an > otherwise unused part of the source tree is the very definition of "out > of sight, out of mind". I was hoping it would say something like PostgreSQL 8.2.0 has been tested with version XX.YY.01 of PL/Whatever You can install it by getting that release and doingthe following. with specific version numbers rather than links to URLS that would change. It that wasn't the intent of the README.TXT, I'm not sure what is. > I can pretty much guarantee you that it will > NOT get updated, especially not during minor releases. Even if it is up > to date at the instant we put out a release, it'll be obsolete as soon > as the external project makes an update release. ISTM links like this > are far better kept on project websites ... I was hoping that this README.TXT point to the specific old version that was tested in much the same way that the old 8.0.0 source tree continues to have the same PL/pgsql that has always been there. If the external project updates their release and breaks compatability I think they should be encouraged to update the README.TXT to say something like PostgreSQL 8.2.1 has been tested with PL/Whatever version XX.YY.99 If they don't make that update, the README would PostgreSQL 8.2.0 has been tested with PL/Whatever version XX.YY.00 >> I would imagine with this README.TXT proposal, it's the responsibility >> of the PL/XXX developer to port their PL to PostgreSQL during the Beta, >> and if the did and tested it, the release will point to the version >> of the PL supported by the PL maintainer for that version. > > And if they didn't? I was just noticing that the current release of > plruby contains installation instructions that appear to date to 7.3. > If he can't be bothered to update his own docs, what are the odds that > he'll submit timely updates for a README in the main source tree? Yeah. Good point. I guess the alternatives are that the README still say PostgreSQL 7.3.0 has been tested with PL/Ruby version X.Y.Z or We are unaware of up-to-date instructions for PL/Ruby. Good Luck. Though if you'd welcome people in the community to submit patches to that README I suspect they'll be updated even more regularly than 2002 or whenever 7.3 come out. If I spent time figuring it out, I wouldn't mind submitting a patch for such a README; and I suspect the other guys who blog about PL/Ruby installation instructions in late 2005 would be happy to submit such patches as well.
Ron Mayer wrote: > Tom Lane wrote: >>> The difference is that I will have reasonable confidence that >>> the README.TXT under "src/pl" will give instructions that match >>> the version of PostgreSQL that I have. I assume that README >>> will call out the version of PL/R or PL/Ruby that I want that >>> was tested with the release of PostgreSQL I have. >> >> On what do you base that assumption? A README file laying about in an >> otherwise unused part of the source tree is the very definition of "out >> of sight, out of mind". > > I was hoping it would say something like > > PostgreSQL 8.2.0 has been tested with version XX.YY.01 of PL/Whatever > You can install it by getting that release and doing the following. > > with specific version numbers rather than links to URLS that would > change. > > It that wasn't the intent of the README.TXT, I'm not sure what is. This is way too DIY. The only thing I think might be worthwhile (and it would help from a buildfarm POV) would be something to assist an integrated build from disparate sources. Just a Readme doesn't come close to what I think we need in the general case. cheers andrew
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> And if that didn't convince you, I still got PL/sh in the wait ... > > It seems like there may be enough interest in PL/Ruby to justify > including it in our distro, but after taking a look at the package > I can see a couple of pretty serious objections: > > 1. Wrong license. Unless the author can be persuaded to relicense as > straight BSD, this discussion is a waste of time. As I mentioned previously, I have already negotiated for a relicense. > > 2. Coding style. The man does not believe in comments; do we really > think anyone else is going to be able to maintain his work? Yes, this was one of my concerns. Sincerely, Joshua D. Drake > > regards, tom lane > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Peter Eisentraut wrote: > Hannu Krosing wrote: >> So we would have >> >> src/pl/plphp/README.TXT >> src/pl/pljava/README.TXT >> src/pl/plj/README.TXT >> >> and anybody looking for pl-s would find the info in a logical place It could be interesting to have something like this: ./configure --with-plruby and it would actually fetch the latest plruby sources from the net and build. Ala Ports. This would take some organization of course, but it would be an relatively easy way to increase our "core" base without bloating core. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Jul 20, 2006, at 8:49 PM, Joshua D. Drake wrote: > It could be interesting to have something like this: > > ./configure --with-plruby > and it would actually fetch the latest plruby sources from the net > and build. Ala Ports. > Or if we didn't want to develop that infastructure of auto-fetching & whatnot we could have --with-plruby output some info like "download foo, put there and rerun configure" (essentially what would be in the src/pl*/README.txt idea). A lot of folks would look at the output of configure --help to see what's available instead of poking around src/pl/* -- Jeff Trout <jeff@jefftrout.com> http://www.dellsmartexitin.com/ http://www.stuarthamm.net/
Josh Berkus wrote: > Neil, > >> (FWIW, I'd be fairly comfortable hacking on PL/Ruby, as I have some >> prior experience with Ruby and its C API.) > > Well, if you're willing to be a maintainer, that removes a major roadblock. > O.k. so we don't loose this. Do we want to work on PL/Ruby in core or not? Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Am Montag, 24. Juli 2006 18:23 schrieb Joshua D. Drake: > O.k. so we don't loose this. Do we want to work on PL/Ruby in core or not? Unless you plan to fork or hijack the package, we need to hear from the author first. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Joshua D. Drake wrote: > Josh Berkus wrote: > >Neil, > > > >>(FWIW, I'd be fairly comfortable hacking on PL/Ruby, as I have some > >>prior experience with Ruby and its C API.) > > > >Well, if you're willing to be a maintainer, that removes a major roadblock. > > > > O.k. so we don't loose this. Do we want to work on PL/Ruby in core or not? Side question -- is it plRuby or PL/Ruby? We should be consistent. I just noticed the top-level README file has all the wrong names -- what is "pl/c" for starters? Or plPgsql? We've _never_ used those names. Also some time ago I convinced you that the actual name for the PHP stuff was PL/php and you agreed. Yet I see on the README the name plPHP which manages to not get a single letter correctly capitalized! I'll patch the README later, but consider this a call for future consistency ... (I'd like to know what do we call "pl/c" though. It's just C, right?) -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Am Montag, 24. Juli 2006 18:49 schrieb Alvaro Herrera: > Side question -- is it plRuby or PL/Ruby? We should be consistent. I > just noticed the top-level README file has all the wrong names -- what > is "pl/c" for starters? Or plPgsql? We've _never_ used those names. I'm beginning to think that this is part of some obscure plot by Joshua Drake to confuse people. I advise all committers not to take any documentation patches from him without careful scrutiny. I've fixed the README. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > Am Montag, 24. Juli 2006 18:23 schrieb Joshua D. Drake: >> O.k. so we don't loose this. Do we want to work on PL/Ruby in core or not? > > Unless you plan to fork or hijack the package, we need to hear from the author > first. What do you want to hear? I have my emails in correspondence asking for the relicense and the approval to submit. Is there something specific you are looking for? Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Peter Eisentraut wrote: > Am Montag, 24. Juli 2006 18:49 schrieb Alvaro Herrera: >> Side question -- is it plRuby or PL/Ruby? We should be consistent. I >> just noticed the top-level README file has all the wrong names -- what >> is "pl/c" for starters? Or plPgsql? We've _never_ used those names. > > I'm beginning to think that this is part of some obscure plot by Joshua Drake > to confuse people. I sincerely hope you are kidding. > I advise all committers not to take any documentation > patches from him without careful scrutiny. Gah... aren't you just all sour grapes. The README was reviewed by several people, in fact it went through two versions to the patches list. Sorry that nobody caught it (including myself), but good lord it isn't that big of a deal. Joshua D. Drake > > I've fixed the README. > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Peter Eisentraut wrote: > Am Montag, 24. Juli 2006 18:49 schrieb Alvaro Herrera: >> Side question -- is it plRuby or PL/Ruby? We should be consistent. I >> just noticed the top-level README file has all the wrong names -- what >> is "pl/c" for starters? Or plPgsql? We've _never_ used those names. > > I'm beginning to think that this is part of some obscure plot by Joshua Drake > to confuse people. I advise all committers not to take any documentation > patches from him without careful scrutiny. > > I've fixed the README. As a secondary note to this, I am by far not the only person that makes the mistake. A simple search on archives shows that. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Joshua D. Drake wrote: > Peter Eisentraut wrote: > >Am Montag, 24. Juli 2006 18:49 schrieb Alvaro Herrera: > >>Side question -- is it plRuby or PL/Ruby? We should be consistent. I > >>just noticed the top-level README file has all the wrong names -- what > >>is "pl/c" for starters? Or plPgsql? We've _never_ used those names. > > > >I'm beginning to think that this is part of some obscure plot by Joshua > >Drake to confuse people. > > I sincerely hope you are kidding. I understand that he is. > >I advise all committers not to take any documentation > >patches from him without careful scrutiny. > > Gah... aren't you just all sour grapes. The README was reviewed by > several people, in fact it went through two versions to the patches list. I saw those fly by and my gut feeling was "whoever commits this is _certainly_ going to fix it". I'm not sure why I didn't comment on it. > Sorry that nobody caught it (including myself), but good lord it isn't > that big of a deal. Consistency is important. It may not be _THAT_ big a deal, but we should be at least a little careful. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>> Sorry that nobody caught it (including myself), but good lord it isn't >> that big of a deal. > > Consistency is important. It may not be _THAT_ big a deal, but we > should be at least a little careful. > I do not disagree. All I was saying was that it is a very common mistake (see secondary note same thread). Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Joshua D. Drake wrote: > What do you want to hear? I have my emails in correspondence asking > for the relicense and the approval to submit. > > Is there something specific you are looking for? Either the author is going to abandon development, then it might make sense to pick up the pieces within the PostgreSQL source tree. But then I'd like to see a specific statement to that effect from him on this list. (I have no reason to believe that he is abandoning, FWIW.) Or the author is agreeing to continue maintenance within the PostgreSQL source tree. Then he should personally talk to us about arranging commit access. If it's neither of these, that is, he will continue to maintain PL/Ruby by himself, and we're just going to copy code back and forth, then we're going to have the pgaccess nightmares all over again, which no one is looking forward to. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > Joshua D. Drake wrote: >> What do you want to hear? I have my emails in correspondence asking >> for the relicense and the approval to submit. >> >> Is there something specific you are looking for? > > Either the author is going to abandon development, then it might make > sense to pick up the pieces within the PostgreSQL source tree. But > then I'd like to see a specific statement to that effect from him on > this list. (I have no reason to believe that he is abandoning, FWIW.) > > Or the author is agreeing to continue maintenance within the PostgreSQL > source tree. Then he should personally talk to us about arranging > commit access. > > If it's neither of these, that is, he will continue to maintain PL/Ruby > by himself, and we're just going to copy code back and forth, then > we're going to have the pgaccess nightmares all over again, which no > one is looking forward to. O.k. yes that all makes sense. I will contact him and see if I can get a thread going between us all. Joshua D. Drake > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Mon, Jul 17, 2006 at 10:45:23AM -0700, Neil Conway wrote: > On Mon, 2006-07-17 at 10:11 -0700, Josh Berkus wrote: > > On the other hand, if we include PL/Perl, Tcl and Python but exclude Ruby > > from the main package we are effectively making a statement to Ruby users > > that their language is inferior in our consideration. > > Hardly -- no more so than not including JDBC and PL/Java in the main CVS > is evidence that we're all Java haters. The fact that we include > PL/Perl, PL/Python and PL/Tcl is more a matter of momentum/historical > accident than an expression of preference, IMHO. External users will not know that, though; they will only see what is and isn't on the list of included PLs. It would be very easy for them to construe that as playing favorites. And to some extent they'd be right, just look at how much of these discussions have focused on how popular different languages are. Ultimately, I really think we need something akin to CPAN so that we don't have to bundle all kinds of stuff in the core package. In the meantime, adding PLs that we can is better than not, but we do need to be mindful of the impression it might leave on users. A page that lists the status of all PLs (specifically why they're not included if they're not) would be a good thing to have. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
> Ultimately, I really think we need something akin to CPAN so that we > don't have to bundle all kinds of stuff in the core package. In the > meantime, adding PLs that we can is better than not, but we do need to > be mindful of the impression it might leave on users. A page that lists > the status of all PLs (specifically why they're not included if they're > not) would be a good thing to have. I as a user think that there should be a clear distinction of what is a supported extension, and what is an unsupported extension . With >100 projects on pgfoundry, 150 or so on gborg, it is hard to tell which ones one can trust, and not everybody wants to beta-test on their production data (especially for things that touch the core engine directly). Maybe there should be a set of requirements fulfilling of which could get a project a special 'blessing' from the Postgresql community? Greetings Marcin Mank