(forw) (forw) Re: PHP 4.0.4pl1 BUILD: BUSTED WITH CURRENT CVS

Larry Rosenman <ler@lerctr.org> writes:

OK, I found it. PHP was including postgres.h (which we no longer
install...., so we were picking up a Feb 7 version).
Changing php's ext/pgsql/php_pgsql.h to #include <postgres_fe.h>
fixes it.

Hm. Should php be including either one? I would have been in less
hurry to invent a new file if I had thought that client apps were
including postgres.h ...

regards, tom lane

* Tom Lane <tgl@sss.pgh.pa.us> [010218 16:54]:

Larry Rosenman <ler@lerctr.org> writes:

OK, I found it. PHP was including postgres.h (which we no longer
install...., so we were picking up a Feb 7 version).
Changing php's ext/pgsql/php_pgsql.h to #include <postgres_fe.h>
fixes it.

Hm. Should php be including either one? I would have been in less
hurry to invent a new file if I had thought that client apps were
including postgres.h ...

hmm. It include libpq-fe.h as well.

regards, tom lane

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

* Tom Lane <tgl@sss.pgh.pa.us> [010218 16:54]:

Larry Rosenman <ler@lerctr.org> writes:

OK, I found it. PHP was including postgres.h (which we no longer
install...., so we were picking up a Feb 7 version).
Changing php's ext/pgsql/php_pgsql.h to #include <postgres_fe.h>
fixes it.

Hm. Should php be including either one? I would have been in less
hurry to invent a new file if I had thought that client apps were
including postgres.h ...

Interestingly, leaving out postgres_fe.h works as well.

I'll update my bug report w/php to delete that line altogether.

regards, tom lane

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

* Tom Lane <tgl@sss.pgh.pa.us> [010218 16:54]:

Larry Rosenman <ler@lerctr.org> writes:

OK, I found it. PHP was including postgres.h (which we no longer
install...., so we were picking up a Feb 7 version).
Changing php's ext/pgsql/php_pgsql.h to #include <postgres_fe.h>
fixes it.

Hm. Should php be including either one? I would have been in less
hurry to invent a new file if I had thought that client apps were
including postgres.h ...

Updated to not include either postgres.h or postgres_fe.h....

FYI, bug # in PHP's DB is 9328.

LER

regards, tom lane

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

I sure hope it gets more attention than some of the other PHP PostgreSQL
bugs.. I don't mean to trash anyone here but the pg_connect problem has been
around since 4.0.1 and has yet to be addressed. One of our programmers is
taking a look at that one but he's not been able to fix it yet.

*crosses fingers*

Is there anything stupendously broken in PG beta 4? I have it on my devel
server and don't want to have to recompile (right now at least, deadlines
are growing close) unless I stand a large chance of pulling the pin on a
grenade somewhere.

Thanks!!

-Mitch

----- Original Message -----
From: "Larry Rosenman" <ler@lerctr.org>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "PostgreSQL Hackers List" <pgsql-hackers@postgresql.org>; "Peter
Eisentraut" <peter_e@gmx.net>; "Bruce Momjian" <pgman@candle.pha.pa.us>
Sent: Sunday, February 18, 2001 6:02 PM
Subject: Re: (forw) (forw) Re: PHP 4.0.4pl1 BUILD: BUSTED WITH CURRENT CVS

"Mitch Vincent" <mitch@venux.net> writes:

Is there anything stupendously broken in PG beta 4?

Other than the bug I introduced into b4 for views containing UNION, a
quick scan of the CVS logs doesn't show any showstoppers fixed in the
backend (dunno what all Peter Mount has been doing in JDBC though).
You could probably hold off updating for a little while.

regards, tom lane

[ Charset ISO-8859-1 unsupported, converting... ]

I sure hope it gets more attention than some of the other PHP PostgreSQL
bugs.. I don't mean to trash anyone here but the pg_connect problem has been
around since 4.0.1 and has yet to be addressed. One of our programmers is
taking a look at that one but he's not been able to fix it yet.

I have worked with Thies on getting persistent connections to work
better. If there are any PostgreSQL problems with PHP, I recommend
sending something to him as he is focused on PostgreSQL recently.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

* Bruce Momjian <pgman@candle.pha.pa.us> [010218 21:23]:

[ Charset ISO-8859-1 unsupported, converting... ]

I sure hope it gets more attention than some of the other PHP PostgreSQL
bugs.. I don't mean to trash anyone here but the pg_connect problem has been
around since 4.0.1 and has yet to be addressed. One of our programmers is
taking a look at that one but he's not been able to fix it yet.

I have worked with Thies on getting persistent connections to work
better. If there are any PostgreSQL problems with PHP, I recommend
sending something to him as he is focused on PostgreSQL recently.

Can you point him at today's fun?

Bug#9328 in PHP's bug DB.

LER

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

FWIW, I emailed Thies about the pg_connect problems, and whis is what he
responded with (yesterday would be Feb 13):

----

i've commited a fix for this to PHP 4 CVS yesterday.

if you don't want to live on the "bleeding edge" (use PHP
from CVS) just replace the php_pgsql_set_default_link
function in pgsql.c against this one and you're all-set!

regards,
tc

static void php_pgsql_set_default_link(int id)
{
PGLS_FETCH();

if ((PGG(default_link) != -1) && (PGG(default_link) != id)) {
zend_list_delete(PGG(default_link));
}

if (PGG(default_link) != id) {
PGG(default_link) = id;
zend_list_addref(id);
}
}

-----

Michael Fork - CCNA - MCP - A+
Network Support - Toledo Internet Access - Toledo Ohio

On Sun, 18 Feb 2001, Bruce Momjian wrote:

Great! Glad to see our PHP interface improving.

FWIW, I emailed Thies about the pg_connect problems, and whis is what he
responded with (yesterday would be Feb 13):

----

i've commited a fix for this to PHP 4 CVS yesterday.

if you don't want to live on the "bleeding edge" (use PHP
from CVS) just replace the php_pgsql_set_default_link
function in pgsql.c against this one and you're all-set!

regards,
tc

static void php_pgsql_set_default_link(int id)
{
PGLS_FETCH();

if ((PGG(default_link) != -1) && (PGG(default_link) != id)) {
zend_list_delete(PGG(default_link));
}

if (PGG(default_link) != id) {
PGG(default_link) = id;
zend_list_addref(id);
}
}

-----

Michael Fork - CCNA - MCP - A+
Network Support - Toledo Internet Access - Toledo Ohio

On Sun, 18 Feb 2001, Bruce Momjian wrote:

[ Charset ISO-8859-1 unsupported, converting... ]

I sure hope it gets more attention than some of the other PHP PostgreSQL
bugs.. I don't mean to trash anyone here but the pg_connect problem has been
around since 4.0.1 and has yet to be addressed. One of our programmers is
taking a look at that one but he's not been able to fix it yet.

I have worked with Thies on getting persistent connections to work
better. If there are any PostgreSQL problems with PHP, I recommend
sending something to him as he is focused on PostgreSQL recently.

-- 
Bruce Momjian                        |  http://candle.pha.pa.us
pgman@candle.pha.pa.us               |  (610) 853-3000
+  If your life is a hard drive,     |  830 Blythe Avenue
+  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Just shoot it over to the PHP folks. Seems they are already on top if
it. I don't want to work around their normal system unless necessary.

* Bruce Momjian <pgman@candle.pha.pa.us> [010218 21:23]:

[ Charset ISO-8859-1 unsupported, converting... ]

I sure hope it gets more attention than some of the other PHP PostgreSQL
bugs.. I don't mean to trash anyone here but the pg_connect problem has been
around since 4.0.1 and has yet to be addressed. One of our programmers is
taking a look at that one but he's not been able to fix it yet.

I have worked with Thies on getting persistent connections to work
better. If there are any PostgreSQL problems with PHP, I recommend
sending something to him as he is focused on PostgreSQL recently.

Can you point him at today's fun?

Bug#9328 in PHP's bug DB.

LER

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

* Bruce Momjian <pgman@candle.pha.pa.us> [010218 22:25]:

Just shoot it over to the PHP folks. Seems they are already on top if
it. I don't want to work around their normal system unless necessary.

Their stuff seems to sit forever. I put it in the BugDB.

I have a couple of other UnixWare issues that have sort of
languished...

Your call Though...

* Bruce Momjian <pgman@candle.pha.pa.us> [010218 21:23]:

[ Charset ISO-8859-1 unsupported, converting... ]

I sure hope it gets more attention than some of the other PHP PostgreSQL
bugs.. I don't mean to trash anyone here but the pg_connect problem has been
around since 4.0.1 and has yet to be addressed. One of our programmers is
taking a look at that one but he's not been able to fix it yet.

I have worked with Thies on getting persistent connections to work
better. If there are any PostgreSQL problems with PHP, I recommend
sending something to him as he is focused on PostgreSQL recently.

Can you point him at today's fun?

Bug#9328 in PHP's bug DB.

LER

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

-- 
Bruce Momjian                        |  http://candle.pha.pa.us
pgman@candle.pha.pa.us               |  (610) 853-3000
+  If your life is a hard drive,     |  830 Blythe Avenue
+  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

On Sun, 18 Feb 2001, Larry Rosenman wrote:

* Bruce Momjian <pgman@candle.pha.pa.us> [010218 22:25]:

Just shoot it over to the PHP folks. Seems they are already on top if
it. I don't want to work around their normal system unless necessary.

Their stuff seems to sit forever. I put it in the BugDB.

The problem here is that we don't plan to release 4.0.5
during the next month. I don't know the exact timeframe for
the release of PostgreSQL 7.0.1, but regular releases of
PostgreSQL/PHP won't compile together for at least some time.
That is rather frustating for the end-user and will delay the
adoption of the new PostgreSQL release.

I have a couple of other UnixWare issues that have sort of
languished...

I found one report which is related to UnixWare's broken
system libraries (#8441). I'll look into working around that
later. If there are others, please point me into their
direction.

Thanks,
- Sascha

On Sun, 18 Feb 2001, Bruce Momjian wrote:

Just shoot it over to the PHP folks. Seems they are already on top if
it. I don't want to work around their normal system unless necessary.

I've committed an autoconf check, so PHP 4.0.5 and upwards
will be compatible with existing and future PostgreSQL
versions. Additionally, discussions about starting the
release process for 4.0.5 have commenced.

It'd be cool, if PostgreSQL and/or the C front-end would have
a numeric version indicator which we could use to check for
features, etc.

#include <libpq-fe.h>
#if defined(PGSQL_FE_VERSION) && PGSQL_FE_VERSION < 20010210
# include <postgres.h>
#endif

- Sascha

* Sascha Schumann <sascha@schumann.cx> [010219 01:37]:

On Sun, 18 Feb 2001, Larry Rosenman wrote:

* Bruce Momjian <pgman@candle.pha.pa.us> [010218 22:25]:

Just shoot it over to the PHP folks. Seems they are already on top if
it. I don't want to work around their normal system unless necessary.

Their stuff seems to sit forever. I put it in the BugDB.

The problem here is that we don't plan to release 4.0.5
during the next month. I don't know the exact timeframe for
the release of PostgreSQL 7.0.1, but regular releases of
PostgreSQL/PHP won't compile together for at least some time.
That is rather frustating for the end-user and will delay the
adoption of the new PostgreSQL release.

I don't believe you will break if that patch is applied now.

I don't have a 7.0 handy to compile against, but I can pull one
if necessary.

I believe it was an error for PHP to #include <postgres.h> at all.

Comments from other -hackers?

I have a couple of other UnixWare issues that have sort of
languished...

I found one report which is related to UnixWare's broken
system libraries (#8441). I'll look into working around that
later. If there are others, please point me into their
direction.

That's the one I was refering to. I submitted it when 4.0.4 came out,
and it didn't even draw a comment till now.... Thanks!

(The other one was the libtool patch which Rasmus did commit).

LER

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

I don't believe you will break if that patch is applied now.

InvalidOid is not defined otherwise.

- Sascha

* Sascha Schumann <sascha@schumann.cx> [010219 07:42]:

I don't believe you will break if that patch is applied now.

InvalidOid is not defined otherwise.

aha. Ok. PG-Hackers: Can we include a Dummy or #warning postgres.h
in 7.1?

I.E.:
#ifndef _POSTGRES_H
#define _POSTGRES_H
#warning Client Code should not include postgres.h
#endif

- Sascha

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

On Mon, 19 Feb 2001, Larry Rosenman wrote:

* Sascha Schumann <sascha@schumann.cx> [010219 07:42]:

I don't believe you will break if that patch is applied now.

InvalidOid is not defined otherwise.

aha. Ok. PG-Hackers: Can we include a Dummy or #warning postgres.h
in 7.1?

#warning is not portable.

As I've mentioned earlier, we already have addressed this
issue. If you want to give it a test, please check out

http://snaps.php.net/

- Sascha

* Bruce Momjian <pgman@candle.pha.pa.us> [010218 22:25]:

Just shoot it over to the PHP folks. Seems they are already on top if
it. I don't want to work around their normal system unless necessary.

Their stuff seems to sit forever. I put it in the BugDB.

I have a couple of other UnixWare issues that have sort of
languished...

I am sorry to hear that. Thies is supposedly working on PostgreSQL
items. Can you contact him directly? He is "Thies C. Arntzen"
<thies@thieso.net>.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sascha Schumann <sascha@schumann.cx> writes:

It'd be cool, if PostgreSQL and/or the C front-end would have
a numeric version indicator which we could use to check for
features, etc.

#include <libpq-fe.h>
#if defined(PGSQL_FE_VERSION) && PGSQL_FE_VERSION < 20010210
# include <postgres.h>
#endif

AFAIK there is no need for you to be including <postgres.h> in *any*
Postgres release --- it's supposed to be an internal header file,
not something that client applications need. Try it with just
#include <libpq-fe.h>

regards, tom lane

Sascha Schumann <sascha@schumann.cx> writes:

I don't believe you will break if that patch is applied now.

InvalidOid is not defined otherwise.

Oh, is that the problem? Okay, do this:

#include <libpq-fe.h>
#ifndef InvalidOid
#define InvalidOid ((Oid) 0)
#endif

I knew there was a reason I'd moved InvalidOid into postgres_ext.h ;-)

regards, tom lane

AFAIK there is no need for you to be including <postgres.h> in *any*
Postgres release --- it's supposed to be an internal header file,
not something that client applications need. Try it with just

/home/sas/src/php4/ext/pgsql/pgsql.c: In function `php_if_pg_getlastoid':
/home/sas/src/php4/ext/pgsql/pgsql.c:1260: `InvalidOid' undeclared (first use in this function)
/home/sas/src/php4/ext/pgsql/pgsql.c:1260: (Each undeclared identifier is reported only once
/home/sas/src/php4/ext/pgsql/pgsql.c:1260: for each function it appears in.)

InvalidOid is used to check the return value of PQoidValue().

src/interfaces/libpq/fe-exec.c:PQoidValue() can return
InvalidOid, so this appears like a legitimate use to me.
Feel free to correct me though, I have not used the C fe
before.

- Sascha

* Sascha Schumann <sascha@schumann.cx> [010219 10:57]:

AFAIK there is no need for you to be including <postgres.h> in *any*
Postgres release --- it's supposed to be an internal header file,
not something that client applications need. Try it with just

/home/sas/src/php4/ext/pgsql/pgsql.c: In function `php_if_pg_getlastoid':
/home/sas/src/php4/ext/pgsql/pgsql.c:1260: `InvalidOid' undeclared (first use in this function)
/home/sas/src/php4/ext/pgsql/pgsql.c:1260: (Each undeclared identifier is reported only once
/home/sas/src/php4/ext/pgsql/pgsql.c:1260: for each function it appears in.)

InvalidOid is used to check the return value of PQoidValue().

src/interfaces/libpq/fe-exec.c:PQoidValue() can return
InvalidOid, so this appears like a legitimate use to me.
Feel free to correct me though, I have not used the C fe
before.

I still think we need a dummy postgres.h in $(destdir)/include to
catch others using it this release. PHP 4.0.4pl1 and earlier will
*BREAK* unless we do.

This is a PROBLEM.

LER

- Sascha

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Larry Rosenman <ler@lerctr.org> writes:

I still think we need a dummy postgres.h in $(destdir)/include to
catch others using it this release. PHP 4.0.4pl1 and earlier will
*BREAK* unless we do.

If we do that, no one will ever fix their code. Moreover, such an
approach would conflict with the install-all-headers option...

regards, tom lane

* Tom Lane <tgl@sss.pgh.pa.us> [010219 15:43]:

Larry Rosenman <ler@lerctr.org> writes:

I still think we need a dummy postgres.h in $(destdir)/include to
catch others using it this release. PHP 4.0.4pl1 and earlier will
*BREAK* unless we do.

If we do that, no one will ever fix their code. Moreover, such an
approach would conflict with the install-all-headers option...

How about a BIG warning in the INSTALL doc, then?

LER

regards, tom lane

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

* Larry Rosenman <ler@lerctr.org> [010219 15:45]:

* Tom Lane <tgl@sss.pgh.pa.us> [010219 15:43]:

Larry Rosenman <ler@lerctr.org> writes:

I still think we need a dummy postgres.h in $(destdir)/include to
catch others using it this release. PHP 4.0.4pl1 and earlier will
*BREAK* unless we do.

If we do that, no one will ever fix their code. Moreover, such an
approach would conflict with the install-all-headers option...

How about a BIG warning in the INSTALL doc, then?

AND make sure we nuke any OLD version in $(destdir)/include... Which
will cause a file not found vs. compile errors based on redeclares...?

LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Larry Rosenman <ler@lerctr.org> writes:

AND make sure we nuke any OLD version in $(destdir)/include... Which
will cause a file not found vs. compile errors based on redeclares...?

Hm. Good point, not only for postgres.h but also for the other include
files we no longer install by default. OTOH, what of people who have
manually added the various spi.h sub-includes to their install directory?
I do not think we should take it on ourselves to clean those out, but
they could still cause cross-version errors.

For the RPM installation this doesn't matter anyway (I think), but it
would for non-RPM installs.

regards, tom lane

Tom Lane wrote:

For the RPM installation this doesn't matter anyway (I think), but it
would for non-RPM installs.

You would be correct, as the old version will be either overwritten
during the new version's install or removed during the previous
version's RPM uninstall. RPM is pretty good at cleaning the old out.
Sometimes a little too good :-/.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

* Larry Rosenman <ler@lerctr.org> [010219 15:55]:

* Larry Rosenman <ler@lerctr.org> [010219 15:45]:

* Tom Lane <tgl@sss.pgh.pa.us> [010219 15:43]:

Larry Rosenman <ler@lerctr.org> writes:

I still think we need a dummy postgres.h in $(destdir)/include to
catch others using it this release. PHP 4.0.4pl1 and earlier will
*BREAK* unless we do.

If we do that, no one will ever fix their code. Moreover, such an
approach would conflict with the install-all-headers option...

How about a BIG warning in the INSTALL doc, then?

AND make sure we nuke any OLD version in $(destdir)/include... Which
will cause a file not found vs. compile errors based on redeclares...?

Thanks for killing the old versions. Now what do we do re PHP
with releases 4.0.4pl1 and earlier which now won't compile against
7.1beta5 and later?

I think we need to do SOMETHING....

LER

LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Larry Rosenman <ler@lerctr.org> writes:

Thanks for killing the old versions. Now what do we do re PHP
with releases 4.0.4pl1 and earlier which now won't compile against
7.1beta5 and later?

I think we need to do SOMETHING....

Frankly, if that's the biggest 7.0-to-7.1 compatibility problem that
we see, I'll be surprised (and pleased). This isn't a problem for
precompiled PHP distributions, and it's a trivial fix for those working
from source. So I don't feel a need to go through any major pushups to
deal with it.

regards, tom lane

Larry Rosenman <ler@lerctr.org> writes:

Thanks for killing the old versions. Now what do we do re PHP
with releases 4.0.4pl1 and earlier which now won't compile against
7.1beta5 and later?

I think we need to do SOMETHING....

Frankly, if that's the biggest 7.0-to-7.1 compatibility problem that
we see, I'll be surprised (and pleased). This isn't a problem for
precompiled PHP distributions, and it's a trivial fix for those working
from source. So I don't feel a need to go through any major pushups to
deal with it.

Sure, let's wait for people to report a problem and we can deal with it
in a minor release.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

but the changes in the include structure force us to.

If someone includes the old ones that aren't supposed to be there, we cause
non-obvious compile errors.

LER

-----Original Message-----
From: Peter Eisentraut [mailto:peter_e@gmx.net]
Sent: Wednesday, February 21, 2001 10:56 AM
To: Larry Rosenman
Cc: Tom Lane; Sascha Schumann; PostgreSQL Hackers List; Bruce Momjian
Subject: Re: [HACKERS] PHP 4.0.4pl1 / Beta 5

Larry Rosenman writes:

AND make sure we nuke any OLD version in $(destdir)/include... Which
will cause a file not found vs. compile errors based on redeclares...?

Deleting files in the install directory during installation is very
inappropriate. At least let's try to get rid of it for 7.2.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Larry Rosenman writes:

AND make sure we nuke any OLD version in $(destdir)/include... Which
will cause a file not found vs. compile errors based on redeclares...?

Deleting files in the install directory during installation is very
inappropriate. At least let's try to get rid of it for 7.2.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:

Larry Rosenman writes:

AND make sure we nuke any OLD version in $(destdir)/include... Which
will cause a file not found vs. compile errors based on redeclares...?

Deleting files in the install directory during installation is very
inappropriate. At least let's try to get rid of it for 7.2.

I don't like it much either, but I agree with Larry that it's an
essential transition step for now. Perhaps we can remove it again
in 7.2 or 7.3 or so.

regards, tom lane

Tom Lane writes:

Deleting files in the install directory during installation is very
inappropriate. At least let's try to get rid of it for 7.2.

I don't like it much either, but I agree with Larry that it's an
essential transition step for now. Perhaps we can remove it again
in 7.2 or 7.3 or so.

I doubt that it ever really worked, or could work, to install a new
version over an old one without deleting the old one first. This here is
just one problem. We can't be making these funny workarounds every time
the set of installed user visible files changes. For example, if an older
version had a header file that the new version doesn't have, then user
code that includes this file will still be silently broken.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

* Peter Eisentraut <peter_e@gmx.net> [010221 16:09]:

Tom Lane writes:

Deleting files in the install directory during installation is very
inappropriate. At least let's try to get rid of it for 7.2.

I don't like it much either, but I agree with Larry that it's an
essential transition step for now. Perhaps we can remove it again
in 7.2 or 7.3 or so.

I doubt that it ever really worked, or could work, to install a new
version over an old one without deleting the old one first. This here is
just one problem. We can't be making these funny workarounds every time
the set of installed user visible files changes. For example, if an older
version had a header file that the new version doesn't have, then user
code that includes this file will still be silently broken.

THIS CHANGED WITHIN A BETA CYCLE. THAT SHOULD HAVE WORKED.

LER

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Peter Eisentraut <peter_e@gmx.net> writes:

I doubt that it ever really worked, or could work, to install a new
version over an old one without deleting the old one first. This here is
just one problem. We can't be making these funny workarounds every time
the set of installed user visible files changes. For example, if an older
version had a header file that the new version doesn't have, then user
code that includes this file will still be silently broken.

Well, the idea is to make the breakage be not so silent ...

regards, tom lane