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/

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 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 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 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.

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 solutions since 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 solutions since 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 solutions since 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 solutions since 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 solutions since 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 solutions since 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 solutions since 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 solutions since 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