> 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 stat
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
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 pic
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 withi
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 sa
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?
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
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 corr
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 th
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
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/
--
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?
Jo
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-fetchin
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 wou
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 serio
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 wi
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 <[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 tha
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 t
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.
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 yo
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/..
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
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/pl
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 p
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 p
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 ad
Ü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, 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
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 broadcas
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 incl
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 :).
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
> compli
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 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 do
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
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 developme
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 coverag
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 effective
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 tha
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,
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 ge
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
peri
45 matches
Mail list logo