Skip site navigation (1) Skip section navigation (2)

Re: R: Fault when return strings over 256 characters in PLpgSQL

From: cathy(dot)hemsley(at)powerconv(dot)alstom(dot)com
To: pgsql-bugs(at)postgresql(dot)org
Cc: Burn! <ml(at)i3fighters(dot)com>
Subject: Re: R: Fault when return strings over 256 characters in PLpgSQL
Date: 2005-03-10 08:45:01
Message-ID: (view raw or whole thread)
Lists: pgsql-bugs
Thanks - we have realised that it is a 'feature' of the pgAdmin III query 
window (if the data is viewed directly then it is correct):  and is listed 
in the pgadmin FAQS as 'query data is truncated'.  Its just a pity they 
don't use something more recognisable such as ... or (...)

Burn ! <ml(at)i3fighters(dot)com>

10/03/2005 08:43

        To:     pgsql-bugs(at)postgresql(dot)org
        cc:     Cathy HEMSLEY/GBRUG03/APC/ALSTOM(at)GA
        Subject:        R: [BUGS] Fault when return strings over 256 characters in PLpgSQL

It could be a pgAdmin III presentation fault.
I'm using PostgreSQL 8.0.0 on Windows 2k and I've got the same problem
but only when inquiring via pgAdmin, using psql from command line all
goes ok. I think that the resulting string are correct, that's why the
function "position(\'.\' in userName);" doesn't find the dot.

Matteo Brusamolin

cathy(dot)hemsley(at)powerconv(dot)alstom(dot)com wrote:
> I have a PLpgSQL function that returns a string (varchar):  if this
> string
> is over 256 characters long then the last three characters are
> replaced by the string ' (.'

I'm skeptical: there is nothing special about 256 characters as far as
the varchar implementation is concerned, nor is the string ' (.' of any

Running your function (albeit on Linux) yields:

neilc=# select testconverttousername();



(1 row)

i.e. what one would expect.


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

CONFIDENTIALITY : This  e-mail  and  any attachments are confidential and 
may be privileged. If  you are not a named recipient, please notify the 
sender immediately and do not disclose the contents to another person, use 
it for any purpose or store or copy the information in any medium.

pgsql-bugs by date

Next:From: Zeugswetter Andreas DAZ SDDate: 2005-03-10 09:17:50
Subject: Re: [HACKERS] We are not following the spec for HAVING without GROUP BY
Previous:From: Burn !Date: 2005-03-10 08:43:58
Subject: R: Fault when return strings over 256 characters in PLpgSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group