On Tue, 3 May 2005, Thomas Hallgren wrote:

> Marc G. Fournier wrote:
>> On Tue, 3 May 2005, Tom Lane wrote:
>>> I think the idea is that plphp would be in our CVS, but would not be
>>> shipped as part of the main tarball, rather as its own separate tarball.
>>
>>
>> That is what I'm hoping for ... if it can be shipped as a seperate tarball,
>> my arguments *against* including it become moot, since packagers (and
>> ports) can have a nice small, quick to download package instead of having
>> to re-download a >11MB file each time ...
>>
>> I don't mind if its *also* ship'd in the main distribution as well, I just
>> want that 'quick to download since I already have the libraries/headers
>> installed' package ...
>>
> Any other PL's not currently in your CVS that you might consider to bring in
> while you're at it?

Personally, if the above condition can be met, my objections for inclusion
of anything into core would pretty much be voided, since it eliminates the
requirement to download a 'monster tar ball' if you don't have to ...

That doesn't say anyone else would have objections, only that I wouldn't
....

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Peter Eisentraut wrote:
> Joshua D. Drake wrote:
>
>>Not really that ugly. It is just an extra compile step. Besides
>>you don't have to package it just because it is in the Tarball.
>
>
> Since you keep raising that point: Not packaging something is not a
> valid solution to something being hard to package.

Except that I don't consider it difficult. I do it all the time, it can
be easily scripted.

Sincerely,

Joshua D. Drake


--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

>>
>> I don't mind if its *also* ship'd in the main distribution as well, I
>> just want that 'quick to download since I already have the
>> libraries/headers installed' package ...
>>
> Any other PL's not currently in your CVS that you might consider to
> bring in while you're at it?

/me heres the sound of the plJava trumpets

>
> Regards,
> Thomas Hallgren
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match


--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Tue, 3 May 2005, Joshua D. Drake wrote:

>>
>> I don't mind if its *also* ship'd in the main distribution as well, I just
>> want that 'quick to download since I already have the libraries/headers
>> installed' package ...
>
> We could break out all of the pls at that point? Where if you downloaded
> postgresql-opt you would get plPHP, plPerl etc...

Optimally, you would get rid of -opt altogether, and leave it as the
individual pl(s) ... the main purposes of the smaller tar balls is so that
someone building a port (*BSDs) or a package (other OSs) would only need
to download the component that applies to them, and someone installing
from source, similar ...

Another benefit would be the ability, for instance, of there being a plPHP
"project" on pgfoundry, where, when a release is made, the tar file is
copied up to there (by the project maintainer, not by me) ... this would
be good to allow sub-projects like this to be able have their own
discussion forms, bug tracking, etc ... while the main code is still
maintained in the main source tree ...

My primary desire is to avoid having to download several Meg of tar
ball(s) in order to add a module to an existing server ... if that can be
accomplished, then my main objection to adding things to the core CVS are
eliminated ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

>
> My primary desire is to avoid having to download several Meg of tar
> ball(s) in order to add a module to an existing server ... if that can
> be accomplished, then my main objection to adding things to the core CVS
> are eliminated ...

I guess I don't see the problem of the PostgreSQL distribution being 11
megs, heck even 50 megs. I know that some places don't have the
bandwidth we do but it only takes me about 90 seconds to download the
distribution.

Sincerely,

Joshua D. Drake


--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Robert Treat wrote:

>
>Is telling the rpm maintainers to go fix their rpm's an option? As has
>been hashed out before, the only thing that makes plphp different from
>other pl's is that some of the current packagers are taking shortcuts
>with the packaging scripts which introduces dependency issues. IMHO what
>is included in the postgresql cvs and what is included in the main
>tarball for postgresql should not be dictated by outside packagers.
>
>
>
>
>

That wasn't my understanding of the previous discussion. Does not php
require pg client support configured in at build time?

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Robert Treat <xzilla@users.sourceforge.net> writes:
> Is telling the rpm maintainers to go fix their rpm's an option? As has
> been hashed out before, the only thing that makes plphp different from
> other pl's is that some of the current packagers are taking shortcuts
> with the packaging scripts which introduces dependency issues. IMHO what
> is included in the postgresql cvs and what is included in the main
> tarball for postgresql should not be dictated by outside packagers.

"Outside packagers"? What makes you think PG RPMs are built by outside
packagers? The PGDG RPMs are certainly built by us, and Red Hat's PG
RPMs are built by somebody named Tom Lane, and last I heard Oliver
Elphick was handling the Debian packaging. We have more control over
those things than you might think. What we don't have control over is
what the PHP people choose to put in their tarball ... and that means
there's a circularity problem if we try to merge plphp. I think you
are blaming the messengers.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

On Tuesday 03 May 2005 13:46, Andrew Dunstan wrote:
> Robert Treat wrote:
> >Is telling the rpm maintainers to go fix their rpm's an option? As has
> >been hashed out before, the only thing that makes plphp different from
> >other pl's is that some of the current packagers are taking shortcuts
> >with the packaging scripts which introduces dependency issues. IMHO what
> >is included in the postgresql cvs and what is included in the main
> >tarball for postgresql should not be dictated by outside packagers.
>
> That wasn't my understanding of the previous discussion. Does not php
> require pg client support configured in at build time?
>

If your compiling it from source, it works similarly to perl... you only need
pg when compiling pg support into php, but you dont need tthis in for plphp.

The problem stems from things like the php rpm spec, which has a module
dependency on postgresql. This would create a circular dependency if we were
to put a dependency into the pg rpm spec for plphp.

I think the solution to this is to create a seperate rpm spec for php-pgsql
support, which would fall in line with how the php rpm packages are
distributed, but I'm not an expert in rpm specs...

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

On Tue, 3 May 2005, Joshua D. Drake wrote:

>
>
>>
>> My primary desire is to avoid having to download several Meg of tar ball(s)
>> in order to add a module to an existing server ... if that can be
>> accomplished, then my main objection to adding things to the core CVS are
>> eliminated ...
>
> I guess I don't see the problem of the PostgreSQL distribution being 11 megs,
> heck even 50 megs. I know that some places don't have the bandwidth we do but
> it only takes me about 90 seconds to download the distribution.

Granted, "we in the West" are lucky ... but I know alot of ppl still on
dialup, and I believe there are still alot of places in Europe (or is/was
it just GB?) that pay per byte for their bandwidth ... even myself, at
home, on a cable modem, have at times found downloads to be atrociously
slow due to load n the network ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

On Tue, 3 May 2005, Marc G. Fournier wrote:

> On Tue, 3 May 2005, Joshua D. Drake wrote:
>
>>
>>
>>>
>>> My primary desire is to avoid having to download several Meg of tar
>>> ball(s) in order to add a module to an existing server ... if that can be
>>> accomplished, then my main objection to adding things to the core CVS are
>>> eliminated ...
>>
>> I guess I don't see the problem of the PostgreSQL distribution being 11
>> megs, heck even 50 megs. I know that some places don't have the bandwidth
>> we do but it only takes me about 90 seconds to download the distribution.
>
> Granted, "we in the West" are lucky ... but I know alot of ppl still on
> dialup, and I believe there are still alot of places in Europe (or is/was it
> just GB?) that pay per byte for their bandwidth ... even myself, at home, on
> a cable modem, have at times found downloads to be atrociously slow due to
> load n the network ...

If anyone knows a *good* source for this sort of thing, please send me a
URL, but a quick search on google finds:


"The market share for permanent connections continued to increase in
December and now accounts for 39.4 per cent of all connections. This
compares with a market share of 21.9 per cent a year before."
http://www.i10.org.uk/pooled/article...NEWSART_136457

Which, to me, indicates that ~60.6% of all connections are still dial-up
(does ISDN count as a permanent connection?) ... but, I don't know where
they are getting their #s from, so, as I said, if someone else can point
me to better stats, please do ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)