ljb <[EMAIL PROTECTED]> writes:
> Confirmed. Perhaps this should be looked into. On my system, "make check"
> works fine if there is no existing PostgreSQL installation. But if there
> is, we seem to prefer the existing installation's libraries over what
> pg_regress sets LD_LIBRARY_PATH to (the ne
[EMAIL PROTECTED] wrote:
> ljb <[EMAIL PROTECTED]> writes:
>> I got the same error with beta1, but the symbol was "get_progname"
>> not "get_proname". Perhaps the above is a typo.
>
> "get_progname" would make sense, because that's a symbol defined in
> libpgport in 7.4 that did not exist in 7.3.
"Dave Hartwig" <[EMAIL PROTECTED]> writes:
> I came across the following problem when migrating from 7.3.4 to 7.4b4.
> Query #4 does not fail under version 7.3.4. But it does under version
> 7.4b4. It seems that in some situations the implicit cast fails.
Fixed in CVS tip. Thanks for the repor
I came across the following problem when migrating from 7.3.4 to 7.4b4.
Query #4 does not fail under version 7.3.4. But it does under version
7.4b4. It seems that in some situations the implicit cast fails. It
would not be a problem if I had the opportunity to manually cast these
queries. But
ljb <[EMAIL PROTECTED]> writes:
> I got the same error with beta1, but the symbol was "get_progname"
> not "get_proname". Perhaps the above is a typo.
"get_progname" would make sense, because that's a symbol defined in
libpgport in 7.4 that did not exist in 7.3. So if the dynamic linker
was findi
