Thread: LIBPQ Question

LIBPQ Question

From
"creid"
Date:
Problem:  Assigning a COUNT(*) result into an integer variable in my C
program consistently fails except when I assign the same result to a char
variable.  I can only assume that the internal data type the COUNT function
uses is integer.

Can anyone help put me in the proper mindset so I may deal with this,
seemingly simple issue, to resolution.

I need the integer result to to help me satisfy a dynamic memory
requirement... COUNT(*) result will tell me how many rows of data I need to
malloc and I cannot perform a math operation on a char variable.

Thanks

Cliff



Re: LIBPQ Question

From
"."@babolo.ru
Date:
> Problem:  Assigning a COUNT(*) result into an integer variable in my C
> program consistently fails except when I assign the same result to a char
> variable.  I can only assume that the internal data type the COUNT function
> uses is integer.
> 
> Can anyone help put me in the proper mindset so I may deal with this,
> seemingly simple issue, to resolution.
> 
> I need the integer result to to help me satisfy a dynamic memory
> requirement... COUNT(*) result will tell me how many rows of data I need to
> malloc and I cannot perform a math operation on a char variable.
As far as I remember count() has bigint result



Re: LIBPQ Question

From
Tomasz Myrta
Date:
Dnia 2003-10-27 00:08, Użytkownik creid napisał:

> Problem:  Assigning a COUNT(*) result into an integer variable in my C
> program consistently fails except when I assign the same result to a char
> variable.  I can only assume that the internal data type the COUNT function
> uses is integer.
> 
> Can anyone help put me in the proper mindset so I may deal with this,
> seemingly simple issue, to resolution.
> 
> I need the integer result to to help me satisfy a dynamic memory
> requirement... COUNT(*) result will tell me how many rows of data I need to
> malloc and I cannot perform a math operation on a char variable.

All libpq results are strings.
some_int_value=atoi(PQgetvalue(...))

Anyway why do you need count(*) ? When you retrieve your rows, you can 
always check how many are them using PQntuples(...) and then malloc your 
memory tables.

Regards,
Tomasz Myrta



Re: LIBPQ Question

From
Igor Shevchenko
Date:
On Monday 27 October 2003 09:15, Tomasz Myrta wrote:
> Dnia 2003-10-27 00:08, Użytkownik creid napisał:
> > Problem:  Assigning a COUNT(*) result into an integer variable in my C
> > program consistently fails except when I assign the same result to a char
> > variable.  I can only assume that the internal data type the COUNT
> > function uses is integer.
> >
> > Can anyone help put me in the proper mindset so I may deal with this,
> > seemingly simple issue, to resolution.
> >
> > I need the integer result to to help me satisfy a dynamic memory
> > requirement... COUNT(*) result will tell me how many rows of data I need
> > to malloc and I cannot perform a math operation on a char variable.
>
> All libpq results are strings.
> some_int_value=atoi(PQgetvalue(...))

Not true anymore with protocol v3, which added the binary format. Text format 
is still the default.

> Anyway why do you need count(*) ? When you retrieve your rows, you can
> always check how many are them using PQntuples(...) and then malloc your
> memory tables.
>
> Regards,
> Tomasz Myrta
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match

-- 
Best regards,
Igor Shevchenko



PGEASY QUESTION

From
"creid"
Date:
I am experimenting with LIBPGEASY

Problem: When I access a "varchar(30)" column using "DECLARE.....FOR SELECT column from schema.table WHERE pkey='KEY'"

When I fetch to a declared variable to return to a calling procedure, my program does a (segmentation error) unless I
declarethe char variable to some much higher value than it is seemingly necessary.  Moreover, the problem does not
occurwhen I manipulate the result in the called procedure.  In fact, in my experimentation, I have noticed that I can
declarea char variable array less than what the result is and it still works.  The crash only occurs in the calling
procedure.

What might I be doing wrong?

Thanks
Cliff

-----Original Message-----
From: pgsql-interfaces-owner@postgresql.org
[mailto:pgsql-interfaces-owner@postgresql.org]On Behalf Of Igor
Shevchenko
Sent: Monday, October 27, 2003 2:25 AM
To: Tomasz Myrta
Cc: pgsql-interfaces@postgresql.org
Subject: Re: [INTERFACES] LIBPQ Question


On Monday 27 October 2003 09:15, Tomasz Myrta wrote:
> Dnia 2003-10-27 00:08, Użytkownik creid napisał:
> > Problem:  Assigning a COUNT(*) result into an integer variable in my C
> > program consistently fails except when I assign the same result to a char
> > variable.  I can only assume that the internal data type the COUNT
> > function uses is integer.
> >
> > Can anyone help put me in the proper mindset so I may deal with this,
> > seemingly simple issue, to resolution.
> >
> > I need the integer result to to help me satisfy a dynamic memory
> > requirement... COUNT(*) result will tell me how many rows of data I need
> > to malloc and I cannot perform a math operation on a char variable.
>
> All libpq results are strings.
> some_int_value=atoi(PQgetvalue(...))

Not true anymore with protocol v3, which added the binary format. Text format
is still the default.

> Anyway why do you need count(*) ? When you retrieve your rows, you can
> always check how many are them using PQntuples(...) and then malloc your
> memory tables.
>
> Regards,
> Tomasz Myrta
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match

--
Best regards,
Igor Shevchenko


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate     subscribe-nomail command to
majordomo@postgresql.orgso that your     message can get through to the mailing list cleanly