(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