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
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
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?
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
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
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
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
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
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_
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
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
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
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
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] 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
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
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/...
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
Peter Eisentraut [EMAIL PROTECTED] 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.
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
Ron Mayer [EMAIL PROTECTED] 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
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
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
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
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
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
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
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
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
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
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
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*
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
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*
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
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
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 :).
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
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
---(end of
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
Ü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
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
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
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
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
45 matches
Mail list logo
