Re: getting a list of users

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(at)mac(dot)com> 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