Re: getting a list of users

[Eric Smith <eric_h_smith@xxxxxxx>]

OK,

So I gave up on the universal binary, and just built a PPC version of postgres.  If I execute the command:

SELECT usename FROM pg_catalog.pg_user;

from within psql, I get:

   usename   

-------------

 esmith

 radiovision

(2 rows)

Seems to work just fine.  If, on the other hand, I issue the same command from within the C API:

NSString* query = [NSString stringWithFormat:@"SELECT usename FROM pg_catalog.pg_user"];

postgresResult = PQexec(myConnection, [query UTF8String]);

I get an error, extracted via:

PQresultErrorMessage(postgresResult)

and the error message is:

status=PGRES_FATAL_ERROR error=<>

I'm connecting to the database through a host IP address, not through localhost.  So, why does this break?

Thanks,

Eric

On May 10, 2009, at 8:39 AM, Tom Lane wrote:

Eric Smith <eric_h_smith@xxxxxxx> writes:

You are correct.  On an Intel, the failed command I mentioned earlier  

works just fine.

I'm building for, and running on, both PPC and Intel.  I've been able  

to avoid these snags in the past, but I'm now adding user management  

to the app, and I'm dead in the water on the PPC.

Just for fun, I tried to reproduce this.  I couldn't figure out what
you'd done to build a dual-arch version of 8.3 --- it certainly would
take more than just passing some funny FLAGS settings to configure.
With CVS HEAD though, the build *does* go through with only a couple
of minor bleats from ranlib, given

CFLAGS='-arch i386 -arch ppc'  LDFLAGS='-arch i386 -arch ppc' configure ...

Building this way on x86 OSX 10.5.6, the resulting binaries work just
fine (of course) on x86.  Not so much on PPC --- I'm surprised it even
gets through initdb, but it does, and I was able to reproduce your
"expected just one rule action".  The regression tests fail rather
miserably though.

Comparing the configure output files, it seems that Apple's compiler
uses the same alignment rules for x86 and ppc, so that the only actual
pg_config.h difference is WORDS_BIGENDIAN.  Which means this probably
would have worked all right in pre-8.3 versions of PG.  But the rules
for short datum headers in 8.3+ will not work at all if the machine
doesn't have the endianness the code thinks.  It looks like the reason
for "expected just one rule action" is that most of the
pg_rewrite.ev_action entries read out as empty C strings --- they are
really text datums of more than 127 bytes and the tuple disaassembly
code is misinterpreting their length words.  I suppose if your app
doesn't deal in fields that are wider than 127 bytes on-disk, you
might have managed to miss realizing that the build was entirely
busted...

So the bottom line seems to be that you need to modify your custom build
procedure to allow for architecture-specific pg_config.h.

regards, tom lane