Обсуждение: (libpq question) Holy cow, what's all this fluff?!

Greetings,

When using the PQgetvalue() function of libpq, the results, at least char
fields, return the value in full, i.e. a char(20) field with the text
"Matthew" for example returns "Matthew             " (all 20 characters,
padded with spaces).

I'm sure there is a good reason for this?  But, none the less, I would like
to turn it off if I can, otherwise I'm off to writing a small function to
strip the spaces off.  This is kind of a pain though because I don't need
to modify the values, just display them, or fill a browser's form fields
with values from the database (which is my biggest need to strip the
fluff).  The docs say that I should not access the structure holding query
results, so I will have to malloc each value, copy it, strip the fluff,
send it out on its way, and release the memory.  More housekeeping, yuck!
Not to mention more processing time.  Please tell me there is a way to get
field values with libpq that are exact to the content length and not the
field length.

Thanks,
Matthew

On Sat, 13 Feb 1999, Matthew Hagerty wrote:
> When using the PQgetvalue() function of libpq, the results, at least char
> fields, return the value in full, i.e. a char(20) field with the text
> "Matthew" for example returns "Matthew             " (all 20 characters,
> padded with spaces).

varchar() perhaps?

-d
--
 This is Linux Country. On a quiet night, you can hear Windows NT reboot!
  Do you remember how to -think- ? Do you remember how to experiment? Linux
__ is an operating system that brings back the fun and adventure in computing.
\/  for linux-kernel: please read linux/Documentation/* before posting problems

On Sat, 13 Feb 1999, Matthew Hagerty wrote:
>Greetings,
>
>When using the PQgetvalue() function of libpq, the results, at least char
>fields, return the value in full, i.e. a char(20) field with the text
>"Matthew" for example returns "Matthew             " (all 20 characters,
>padded with spaces).

You want a varchar (or is it bpchar?), not a char. char(x) will always return x
characters, with space padding if necessary.

Taral

> You want a varchar (or is it bpchar?), not a char. char(x) will always
> return x characters, with space padding if necessary.

"bpchar" == "blank padded char", which is what char() is mapped to
internally. As Matthew has already learned, he probably really wants to
be using varchar(), or fix it up with trim().

                       - Tom

At 04:30 AM 2/14/99 +0000, Thomas G. Lockhart wrote:
>> You want a varchar (or is it bpchar?), not a char. char(x) will always
>> return x characters, with space padding if necessary.
>
>"bpchar" == "blank padded char", which is what char() is mapped to
>internally. As Matthew has already learned, he probably really wants to
>be using varchar(), or fix it up with trim().
>
>                       - Tom

Yeah, but the docs say you get a performance hit for using varchar, text,
and the like.  Which is worse, the database performance hit or the extra
call to trim for every char field?

Matthew

Matthew Hagerty <matthew@venux.net> writes:
> At 04:30 AM 2/14/99 +0000, Thomas G. Lockhart wrote:
>>> You want a varchar (or is it bpchar?), not a char. char(x) will always
>>> return x characters, with space padding if necessary.

> Yeah, but the docs say you get a performance hit for using varchar, text,
> and the like.  Which is worse, the database performance hit or the extra
> call to trim for every char field?

Whatever docs you are looking at are obsolete.  char(n), varchar(n), and
text have essentially interchangeable performance and representation.
They all have a length word and some characters.

(I've griped about that myself --- particularly that plain "char" is
effectively an 8-byte field, not a 1-byte field like you'd expect.
Nobody else seems worried about it though.)

I'd recommend using "text", personally, unless you have a specific
reason for imposing an upper length limit on the string.

            regards, tom lane