Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
Peter Eisentraut [EMAIL PROTECTED] 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
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
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 [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Peter Eisentraut [EMAIL PROTECTED] [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 [EMAIL PROTECTED] http://yi.org/peter-e/ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
Peter Eisentraut [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] http://yi.org/peter-e/
RE: [HACKERS] PHP 4.0.4pl1 / Beta 5
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:[EMAIL PROTECTED]] 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 [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
Larry Rosenman [EMAIL PROTECTED] 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
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Larry Rosenman [EMAIL PROTECTED] [010219 15:55]: * Larry Rosenman [EMAIL PROTECTED] [010219 15:45]: * Tom Lane [EMAIL PROTECTED] [010219 15:43]: Larry Rosenman [EMAIL PROTECTED] 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: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
Larry Rosenman [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
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
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Sascha Schumann [EMAIL PROTECTED] [010219 01:37]: On Sun, 18 Feb 2001, Larry Rosenman wrote: * Bruce Momjian [EMAIL PROTECTED] [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: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
I don't believe you will break if that patch is applied now. InvalidOid is not defined otherwise. - Sascha
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Sascha Schumann [EMAIL PROTECTED] [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: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
On Mon, 19 Feb 2001, Larry Rosenman wrote: * Sascha Schumann [EMAIL PROTECTED] [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
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Bruce Momjian [EMAIL PROTECTED] [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" [EMAIL PROTECTED]. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
Sascha Schumann [EMAIL PROTECTED] 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
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
Sascha Schumann [EMAIL PROTECTED] 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
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
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
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Sascha Schumann [EMAIL PROTECTED] [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: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
Larry Rosenman [EMAIL PROTECTED] 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
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Tom Lane [EMAIL PROTECTED] [010219 15:43]: Larry Rosenman [EMAIL PROTECTED] 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: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Larry Rosenman [EMAIL PROTECTED] [010219 15:45]: * Tom Lane [EMAIL PROTECTED] [010219 15:43]: Larry Rosenman [EMAIL PROTECTED] 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: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
old include files (was Re: [HACKERS] PHP 4.0.4pl1 / Beta 5)
Larry Rosenman [EMAIL PROTECTED] 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
Re: old include files (was Re: [HACKERS] PHP 4.0.4pl1 / Beta 5)
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
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
"Mitch Vincent" [EMAIL PROTECTED] 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
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Bruce Momjian [EMAIL PROTECTED] [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: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
[ 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 [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
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
[EMAIL PROTECTED] | (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
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
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 [EMAIL PROTECTED] [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: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
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
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Bruce Momjian [EMAIL PROTECTED] [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 [EMAIL PROTECTED] [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: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
On Sun, 18 Feb 2001, Larry Rosenman wrote: * Bruce Momjian [EMAIL PROTECTED] [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
