Mike Landis mlan...@pnmx.com writes:
When I execute the following SQL:
SELECT COUNT(*) FROM information_schema.tables WHERE table_name='proxies'
in the PGAdmmin 1.10.0, rev 7945-7946 query tool, I get 1 (the correct
answer). When I run the exact same SQL in a C program, I get a result set
Try the following, where
mystring is an extension of std::string...
mystring sql( SELECT COUNT(*) FROM information_schema.tables
WHERE table_name='proxies' );
int
GetIntFromSQL(
mystring sql )
{
// if there's more than one
record in the ResultSet, still only returns the first float
int
On Thu, Jan 7, 2010 at 7:51 AM, Mike Landis mlan...@pnmx.com wrote:
Try the following, where mystring is an extension of std::string...
It seems to me this would be a lot easier if you could attach a
complete program that someone could just compile, instead of code
fragments that are missing
Mike Landis wrote:
html
body
font color=#FFPick a database and table that exists, configure
the string cconstants, compile and run the attached cpp, get 0 instead of
1 (that you get in pgAdmin...brbr
You realize that information_schema only shows you tables that have
permissions on,
Mike Landis wrote:
Pick a database and table that exists, configure the string
cconstants, compile and run the attached cpp, get 0 instead of 1 (that
you get in pgAdmin...
Where's can I download the libpq source? Maybe I can find and/or fix
the problem myself.
Your program works fine for
On Thu, Jan 7, 2010 at 7:31 PM, Mark Kirkwood
mark.kirkw...@catalyst.net.nz wrote:
Mike Landis wrote:
Pick a database and table that exists, configure the string cconstants,
compile and run the attached cpp, get 0 instead of 1 (that you get in
pgAdmin...
Where's can I download the libpq
(I forgot to cc -bugs...)
Mike Landis wrote:
Two things strike me as odd about that...
1) What's the logic behind the owner of a table not automatically
getting a readonly privilege like SELECT?
Owner always has select on a table they have created.
2) I think it would be more logical to
Mike Landis wrote:
At 09:09 PM 1/7/2010, you wrote:
I suspect they do not. Its all in the permissions.
There's no user account control enabled on this Vista machine,
therefore effectively wide open, hence different platform behavior or
at least a difference between the behavior in pgAdmin
The following bug has been logged online:
Bug reference: 5268
Logged by: Mike Landis
Email address: mlan...@pnmx.com
PostgreSQL version: 8.4.1
Operating system: Vista
Description:PQgetvalue incorrectly returns 0
Details:
When I execute the following SQL:
SELECT