Thread: BUG #5318: Inconsistent PHP pg_result_error_field PGSQL_DIAG_SOURCE_FUNCTION across instalations

The following bug has been logged online:

Bug reference:      5318
Logged by:          IP
Email address:      ireneusz.pastusiak@poczta.fm
PostgreSQL version: 8.4.2
Operating system:   Sun Solaris 10 x86
Description:        Inconsistent PHP pg_result_error_field
PGSQL_DIAG_SOURCE_FUNCTION across instalations
Details:

I have already posted this issue to pgsql-bugs list, but in incorrect
version: http://archives.postgresql.org/pgsql-bugs/2010-02/msg00034.php

Now posting it via Bug Reporting form. I believe this is not PHP, but DB
engine issue, as specified below.

PHP Script:

<?php


if($c = pg_connect("host=192.168.0.10 dbname=xxx user=xxx password=xxx
port=5432")) {

echo "Successfully connected to PostgreSQL 8.4.2 by Enterprise DB @ Windows
Vista x86<br>";

$s = "DROP TABLE t123;"; // table doesn't exist

pg_send_query($c, $s);

$r = pg_get_result($c);

echo "Source function: " . pg_result_error_field($r,
PGSQL_DIAG_SOURCE_FUNCTION) . "<br><br>";

pg_close($c);

}


if($c = pg_connect("host=192.168.0.60 dbname=xxx user=xxx password=xxx
port=5432")) {

echo "Successfully connected to PostgreSQL 8.4.2 (installed from package) @
Sun Solaris 10 x86<br>";

$s = "DROP TABLE t123;"; // table doesn't exist

pg_send_query($c, $s);

$r = pg_get_result($c);

echo "Source function: " . pg_result_error_field($r,
PGSQL_DIAG_SOURCE_FUNCTION) . "<br><br>";

pg_close($c);

}


if($c = pg_connect("host=192.168.0.60 dbname=xxx user=xxx password=xxx
port=5431")) {

echo "Successfully connected to PostgreSQL 8.5alpha3 (installed from source)
@ Sun Solaris 10 x86<br>";

$s = "DROP TABLE t123;"; // table doesn't exist

pg_send_query($c, $s);

$r = pg_get_result($c);

echo "Source function: " . pg_result_error_field($r,
PGSQL_DIAG_SOURCE_FUNCTION) . "<br><br>";

pg_close($c);

}


?>



###############################################

Output:

Successfully connected to PostgreSQL 8.4.2 by Enterprise DB @ Windows Vista
x86
Source function: DropErrorMsgNonExistent

Successfully connected to PostgreSQL 8.4.2 (installed from package) @ Sun
Solaris 10 x86
Source function:

Successfully connected to PostgreSQL 8.5alpha3 (installed from source) @ Sun
Solaris 10 x86
Source function: DropErrorMsgNonExistent

###############################################
Issue: no value returned for 8.4.2 Solaris 10 x86 installation

"IP" <ireneusz.pastusiak@poczta.fm> writes:
> Issue: no value returned for 8.4.2 Solaris 10 x86 installation

This isn't necessarily a bug.  The source-function report depends
on having used a C compiler that supports the __func__ or __FUNCTION__
symbol, and not all do.  Most likely your Solaris 10 version was
built with a compiler that doesn't.

            regards, tom lane

That seems to be the reason. I have just installed 8.4.2 from source using
/usr/sfw/bin/gcc
and the function is working now. The version with function that didn't
return anything was installed from package, so I will try to contact
maintainer - maybe there is a chance this functionality.


----------------------------------------------------------------------
Sprawdz jak dobrze sie znacie!
Stworz wlasny quiz >>> http://link.interia.pl/f25ab

Tom Lane píše v so 06. 02. 2010 v 10:57 -0500:
> "IP" <ireneusz.pastusiak@poczta.fm> writes:
> > Issue: no value returned for 8.4.2 Solaris 10 x86 installation
>
> This isn't necessarily a bug.  The source-function report depends
> on having used a C compiler that supports the __func__ or __FUNCTION__
> symbol, and not all do.

Yes it is the problem

> Most likely your Solaris 10 version was
> built with a compiler that doesn't.

SunStudio has __func__ since version 10. Solaris 10 is compiled with
version 11. Problem is that __func__ is defined in C99 and PostgreSQL is
compiled with -xc99=none. Which means that compiler should be strict C89
like PostgreSQL ;-).

I think that there is no reason to use this flag.

    Zdenek

What is the final outcome? Will the Sun Solaris' PostgreSQL 8.4.2 packages
be rebuild so that PGSQL_DIAG_SOURCE_FUNCTION is operational, or rather not?


----------------------------------------------------------------------
Szybkie i niedrogie... Tylko dla mezczyzn!
Sprawdz >>> http://link.interia.pl/f25a7

We (means postgresql community -> Bjorn or me) will fix it in 8.4.3
packages. It will be confusing to rerelease already released 8.4.2
package.

Just for clarification, There is no Sun's Solaris 10 PostgreSQL 8.4
packages.

    Zdenek


IP píše v ne 14. 02. 2010 v 20:39 +0100:
> What is the final outcome? Will the Sun Solaris' PostgreSQL 8.4.2 packages
> be rebuild so that PGSQL_DIAG_SOURCE_FUNCTION is operational, or rather not?
>
>
> ----------------------------------------------------------------------
> Szybkie i niedrogie... Tylko dla mezczyzn!
> Sprawdz >>> http://link.interia.pl/f25a7
>

Hi,

Thanks, great info. I will retest that, for sure. Nevertheless status of
PostgreSQL packages for Sun Solaris is something really interesting ;-) Here
http://www.postgresql.org/download/solaris we can read that the packages are
produced by Sun. That's the reason I call them that way.

Many thanks,


----------------------------------------------------------------------
Codziennie 11 tys. ofert pracy
Sprawdz >>> http://link.interia.pl/f25ac

IP píše v ne 14. 02. 2010 v 21:15 +0100:
> Hi,
>
> Thanks, great info. I will retest that, for sure. Nevertheless status of
> PostgreSQL packages for Sun Solaris is something really interesting ;-) Here
> http://www.postgresql.org/download/solaris we can read that the packages are
> produced by Sun. That's the reason I call them that way.

They are community packages and people from Sun only produce it but Sun
does not guarantee quality and so on.  It is same like RPM or other
packages. People from different companies do that but companies are not
responsible for the content. It  could look like little bit
schizophrenic :-), but it is how it works.


    Zdenek