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
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
* 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
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.
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.
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
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
* 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
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
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
* 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.
I don't believe you will break if that patch is applied now.
InvalidOid is not defined otherwise.
- Sascha
* 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
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?
* 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
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
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
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':
* 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
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
* 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
* 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
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.
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
"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
* 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
[ 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
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
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
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
* 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
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
32 matches
Mail list logo
