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
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]> 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
> inappropr
* 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
> > ess
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
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 visi
> 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
* 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 ot
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 p
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
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.
* 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
> >
* 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 f
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 w
* Sascha Schumann <[EMAIL PROTECTED]> [010219 10:57]:
> > AFAIK there is no need for you to be including 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
> AFAIK there is no need for you to be including 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/pg
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
#ifndef InvalidOid
#define InvalidOid ((Oid) 0)
#endif
I kne
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
> #if defined(PGSQL_FE_VERSION) && PGSQL_FE_VERSION < 20010210
> # include
> * 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 Uni
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
* 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
#war
> I don't believe you will break if that patch is applied now.
>
InvalidOid is not defined otherwise.
- Sascha
* 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 unle
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 futu
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 t
* 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
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_l
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
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 edg
[ 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
* 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 t
"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
32 matches
Mail list logo
