Thread: (forw) (forw) Re: PHP 4.0.4pl1 BUILD: BUSTED WITH CURRENT CVS
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. This is a gotcha for people following CVS or not cleaning out the $(DESTDIR)/include directory I'll submit a patch to the PHP folk. LER ----- Forwarded message from Larry Rosenman <ler@lerctr.org> ----- From: Larry Rosenman <ler@lerctr.org> Subject: (forw) Re: [HACKERS] PHP 4.0.4pl1 BUILD: BUSTED WITH CURRENT CVS Date: Sun, 18 Feb 2001 14:50:32 -0600 Message-ID: <20010218145032.A6190@lerami.lerctr.org> User-Agent: Mutt/1.3.15i X-Mailer: Mutt http://www.mutt.org/ To: PostgreSQL Hackers List <pgsql-hackers@postgresql.org>,tgl@sss.pgh.pa.us, Peter Eisentraut <peter_e@gmx.net> Re-Sent due to bounce from ftp.postgresql.org ----- Forwarded message from Larry Rosenman <ler@lerctr.org> ----- From: Larry Rosenman <ler@lerctr.org> Subject: Re: [HACKERS] PHP 4.0.4pl1 BUILD: BUSTED WITH CURRENT CVS Date: Sun, 18 Feb 2001 14:41:33 -0600 Message-ID: <20010218144133.A5745@lerami.lerctr.org> User-Agent: Mutt/1.3.15i X-Mailer: Mutt http://www.mutt.org/ To: PostgreSQL Hackers List <pgsql-hackers@postgresql.org> * Larry Rosenman <ler@lerctr.org> [010218 14:19]: > PHP 4.0.4pl1 Build dies with current CVS: > Making all in pgsql > gmake[2]: Entering directory `/home/ler/php/ext/pgsql' > gmake[3]: Entering directory `/home/ler/php/ext/pgsql' > /bin/sh /home/ler/php/libtool --silent --mode=compile cc -Xb -I. > -I/home/ler/php/ext/pgsql -I/home/ler/php/main -I/home/ler/php > -I/usr/internet/apache/include -I/home/ler/php/Zend > -I/usr/local/ssl/include -I/usr/local/include > -I/home/ler/php/ext/xml/expat/xmltok > -I/home/ler/php/ext/xml/expat/xmlparse -I/home/ler/php/TSRM > -I/usr/local/pgsql/include -DNDEBUG -DUW=700 -DUSE_HSREGEX -DUSE_EXPAT > -DXML_BYTE_ORDER=12 -O -c pgsql.c > UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 53: > typedef redeclared: regproc > UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 54: > typedef redeclared: RegProcedure > UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 69: > (struct) tag redeclared: varlena > UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 87: > identifier redeclared: bytea > UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 88: > identifier redeclared: text > UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 89: > identifier redeclared: BpChar > UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 90: > identifier redeclared: VarChar > UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 171: > typedef redeclared: int2vector > UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 172: > typedef redeclared: oidvector > UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 179: > (union) tag redeclared: nameData > UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 182: > identifier redeclared: NameData > UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 183: > identifier redeclared: Name > UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 192: > typedef redeclared: TransactionId > UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 196: > typedef redeclared: CommandId > gmake[3]: *** [pgsql.lo] Error 1 > gmake[3]: Leaving directory `/home/ler/php/ext/pgsql' > gmake[2]: *** [all-recursive] Error 1 > gmake[2]: Leaving directory `/home/ler/php/ext/pgsql' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/home/ler/php/ext' > gmake: *** [all-recursive] Error 1 > $ more info, courtesy gcc: $ sh x gcc: unrecognized option `-KPIC' In file included from php_pgsql.h:32, from pgsql.c:29: /usr/local/pgsql/include/postgres.h:53: redefinition of `regproc' /usr/local/pgsql/include/c.h:312: `regproc' previously declared here /usr/local/pgsql/include/postgres.h:54: redefinition of `RegProcedure' /usr/local/pgsql/include/c.h:313: `RegProcedure' previously declared here /usr/local/pgsql/include/postgres.h:69: redefinition of `struct varlena' /usr/local/pgsql/include/postgres.h:87: redefinition of `bytea' /usr/local/pgsql/include/c.h:354: `bytea' previously declared here /usr/local/pgsql/include/postgres.h:88: redefinition of `text' /usr/local/pgsql/include/c.h:355: `text' previously declared here /usr/local/pgsql/include/postgres.h:89: redefinition of `BpChar' /usr/local/pgsql/include/c.h:356: `BpChar' previously declared here /usr/local/pgsql/include/postgres.h:90: redefinition of `VarChar' /usr/local/pgsql/include/c.h:357: `VarChar' previously declared here /usr/local/pgsql/include/postgres.h:171: redefinition of `int2vector' /usr/local/pgsql/include/c.h:363: `int2vector' previously declared here /usr/local/pgsql/include/postgres.h:172: redefinition of `oidvector' /usr/local/pgsql/include/c.h:364: `oidvector' previously declared here /usr/local/pgsql/include/postgres.h:179: redefinition of `union nameData' /usr/local/pgsql/include/postgres.h:182: redefinition of `NameData' /usr/local/pgsql/include/c.h:375: `NameData' previously declared here /usr/local/pgsql/include/postgres.h:183: redefinition of `Name' /usr/local/pgsql/include/c.h:376: `Name' previously declared here /usr/local/pgsql/include/postgres.h:192: redefinition of `TransactionId' /usr/local/pgsql/include/c.h:315: `TransactionId' previously declared here /usr/local/pgsql/include/postgres.h:196: redefinition of `CommandId' /usr/local/pgsql/include/c.h:319: `CommandId' previously declared here $ > > -- > 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 ----- End forwarded message ----- -- 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 ----- End forwarded message ----- -- 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:
> 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 ... > 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 ... 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 ... 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 > * 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 >
"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, Pennsylvania19026
* 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
functionin 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
>
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,
Pennsylvania19026
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, Pennsylvania19026
* 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 checkfor 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, Pennsylvania19026
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. Feelfree 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> 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> [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. 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, Pennsylvania19026
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/
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/
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