On Mon, 2 May 2005, Bruce Momjian wrote:

> I posted this compromise and no one replied so I thought everyone was OK
> with it. It gets it into CVS, but has a separate compile stage to deal
> with the recursive dependency problem.

Then what is the point of having it in CVS? Other then to make are tar
ball bigger?

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

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

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

Marc G. Fournier wrote:
> On Mon, 2 May 2005, Bruce Momjian wrote:
>
> > I posted this compromise and no one replied so I thought everyone was OK
> > with it. It gets it into CVS, but has a separate compile stage to deal
> > with the recursive dependency problem.
>
> Then what is the point of having it in CVS? Other then to make are tar
> ball bigger?

So it can be maintained with other PL languages as the internal API
changes. This is the same reason ecpg is in our CVS because it is tied
to the grammar.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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

On Mon, 2 May 2005, Bruce Momjian wrote:

> Marc G. Fournier wrote:
>> On Mon, 2 May 2005, Bruce Momjian wrote:
>>
>>> I posted this compromise and no one replied so I thought everyone was OK
>>> with it. It gets it into CVS, but has a separate compile stage to deal
>>> with the recursive dependency problem.
>>
>> Then what is the point of having it in CVS? Other then to make are tar
>> ball bigger?
>
> So it can be maintained with other PL languages as the internal API
> changes. This is the same reason ecpg is in our CVS because it is tied
> to the grammar.

Since when? I thought you didn't need the PostgreSQL sources in order to
compile pl/PHP, only the installed headers/libraries ... Joshua, has
something changed, or did I mis-understand that requirement?

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

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

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

Marc G. Fournier wrote:
> On Mon, 2 May 2005, Bruce Momjian wrote:
>
> > Marc G. Fournier wrote:
> >> On Mon, 2 May 2005, Bruce Momjian wrote:
> >>
> >>> I posted this compromise and no one replied so I thought everyone was OK
> >>> with it. It gets it into CVS, but has a separate compile stage to deal
> >>> with the recursive dependency problem.
> >>
> >> Then what is the point of having it in CVS? Other then to make are tar
> >> ball bigger?
> >
> > So it can be maintained with other PL languages as the internal API
> > changes. This is the same reason ecpg is in our CVS because it is tied
> > to the grammar.
>
> Since when? I thought you didn't need the PostgreSQL sources in order to
> compile pl/PHP, only the installed headers/libraries ... Joshua, has
> something changed, or did I mis-understand that requirement?

The issue is that we have had to wack around the existing PL languages
for almost every release to make them work with server changes, and
being outside our CVS, plPHP isn't getting that whacking.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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

>
>
> Since when? I thought you didn't need the PostgreSQL sources in order
> to compile pl/PHP, only the installed headers/libraries ... Joshua, has
> something changed, or did I mis-understand that requirement?

Well we don't modify the backend or anything but the way plPHP is
written it assumes it is part of the tree, which is why we have to patch.

However I think part of the argument goes to API. For example the latest
release of plPHP will not work with 7.4.

Sincerely,

Joshua D. Drake


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


--
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 Mon, 2 May 2005, Bruce Momjian wrote:

> Marc G. Fournier wrote:
>> On Mon, 2 May 2005, Bruce Momjian wrote:
>>
>>> Marc G. Fournier wrote:
>>>> On Mon, 2 May 2005, Bruce Momjian wrote:
>>>>
>>>>> I posted this compromise and no one replied so I thought everyone was OK
>>>>> with it. It gets it into CVS, but has a separate compile stage to deal
>>>>> with the recursive dependency problem.
>>>>
>>>> Then what is the point of having it in CVS? Other then to make are tar
>>>> ball bigger?
>>>
>>> So it can be maintained with other PL languages as the internal API
>>> changes. This is the same reason ecpg is in our CVS because it is tied
>>> to the grammar.
>>
>> Since when? I thought you didn't need the PostgreSQL sources in order to
>> compile pl/PHP, only the installed headers/libraries ... Joshua, has
>> something changed, or did I mis-understand that requirement?
>
> The issue is that we have had to wack around the existing PL languages
> for almost every release to make them work with server changes, and
> being outside our CVS, plPHP isn't getting that whacking.

And the point is, as Tom has pointed out with tsearch2, that even *in*
CVS, it is a fair amount of work to 'whack' other ppls code ... it
shouldn't be Tom's responsibility (which is generally what it comes down
to) to keep someone else's code up to speed with changes in the server ...

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

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

>>
>> The issue is that we have had to wack around the existing PL languages
>> for almost every release to make them work with server changes, and
>> being outside our CVS, plPHP isn't getting that whacking.
>
>
> And the point is, as Tom has pointed out with tsearch2, that even *in*
> CVS, it is a fair amount of work to 'whack' other ppls code ... it
> shouldn't be Tom's responsibility (which is generally what it comes down
> to) to keep someone else's code up to speed with changes in the server ...

Well we try to keep up


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


--
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 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

"Marc G. Fournier" <scrappy@postgresql.org> writes:
> On Mon, 2 May 2005, Bruce Momjian wrote:
>> Marc G. Fournier wrote:
>>> Then what is the point of having it in CVS? Other then to make are tar
>>> ball bigger?
>>
>> So it can be maintained with other PL languages as the internal API
>> changes. This is the same reason ecpg is in our CVS because it is tied
>> to the grammar.

> Since when? I thought you didn't need the PostgreSQL sources in order to
> compile pl/PHP, only the installed headers/libraries ... Joshua, has
> something changed, or did I mis-understand that requirement?

That could be said of *any* of our PLs (at least now that we install all
server-side headers by default ;-)). I think the real reason we keep
pltcl etc in the core CVS is exactly what Bruce said: it's easier to
maintain 'em that way. The problem is that the PLs use all sorts of
internal backend APIs that we don't want to freeze, and so they are
constantly being affected by changes in the core backend. Just look
at the CVS logs for evidence.

Personally, I'm willing to fix the PLs whenever I make a change that
affects them, but only if they're in core CVS. Dealing with parallel
changes in two different code repositories is too much of a pain.
So the folks maintaining non-core PLs take a big hit every release when
they have to sync with what's happened in the core backend meanwhile.

regards, tom lane

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

On Mon, 2 May 2005, Joshua D. Drake wrote:

>>>
>>> The issue is that we have had to wack around the existing PL languages
>>> for almost every release to make them work with server changes, and
>>> being outside our CVS, plPHP isn't getting that whacking.
>>
>>
>> And the point is, as Tom has pointed out with tsearch2, that even *in* CVS,
>> it is a fair amount of work to 'whack' other ppls code ... it shouldn't be
>> Tom's responsibility (which is generally what it comes down to) to keep
>> someone else's code up to speed with changes in the server ...
>
> Well we try to keep up

I'm not pointing fingers at you either But, you are one of how many
that try and get 'added to core'? How many things do we have in contrib
that the only person that does any 'whacking' is Tom? A couple I've seen
patches go around for, but for a good portion of them, I imagine that they
are 'dead except that Tom keeps fixing them' ...

Tom's focus shouldn't be making sure that everyone's third party add on
"still works" during a release cycle, that should be the responsibility of
the maintainers of those projects, to follow changes and make sure they
are implemented ...

That is what pgFoundry was setup for ... to give projects the visibiilty
they would get through the core distribution by making sure they are
referenced in a central place, but providing the maintainers with direct
CVS access to make changes to their code in a timely manner .. *shrug*


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

>
> I'm not pointing fingers at you either But, you are one of how many
> that try and get 'added to core'? How many things do we have in contrib
> that the only person that does any 'whacking' is Tom? A couple I've
> seen patches go around for, but for a good portion of them, I imagine
> that they are 'dead except that Tom keeps fixing them' ...

In contrib I would bet a lot. I have argued for the removal of TSearch
(not TSearch2) for example. Also RServ could probably stand to be removed.

However we are not talking about contrib (or at least I am not). We were
talking about PLs which are a little bit of a different beast.

> Tom's focus shouldn't be making sure that everyone's third party add on
> "still works" during a release cycle, that should be the responsibility
> of the maintainers of those projects, to follow changes and make sure
> they are implemented ...

I would agree, I suggested test cases for contrib once. I think that
would be very good. If the contrib fails the test case for itself say
after (this could go for pls to) Beta2 then it gets yanked.

> That is what pgFoundry was setup for ... to give projects the visibiilty
> they would get through the core distribution by making sure they are
> referenced in a central place, but providing the maintainers with direct
> CVS access to make changes to their code in a timely manner .. *shrug*

It was what pgFoundry was setup for but as I have said elsewhere
perception is everything.

If it isn't in core, it is a second class project. Regardless of how we
all "want" to feel about it.

Sincerely,

Joshua D. Drake
Command Prompt, Inc.




--
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 8: explain analyze is your friend