plPHP and plRuby

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 solutions since 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 solutions since 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 solutions since 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 => "<repo locn>", 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 solutions since 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 solutions since 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/

Ü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

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/