From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Bozena Potempa" <Bozena(dot)Potempa(at)otc(dot)pl> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Libpq: PQftype, PQfsize |
Date: | 2010-08-12 14:15:57 |
Message-ID: | 13440.1281622557@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Bozena Potempa" <Bozena(dot)Potempa(at)otc(dot)pl> writes:
> Thank you. In this case (substring) there is no much to predict, just a
> simple calculation, but I understand that it is a part of larger and more
> complicated functionality. I tried to find a workaround with a type cast:
> select substr(fc,1,2)::varchar(2) from test
> Now the type returned is varchar, but the size is still -1. I think that it
> is not a correct return: the size is specified explicitly in the query and
> could be used by PQfsize.
Oh ... actually the problem there is that you have the wrong idea about
what PQfsize means. What that returns is pg_type.typlen for the data
type, which is always going to be -1 for a varlena type like varchar.
The thing that you need to look at if you want to see information like
the max length of a varchar is typmod (PQfmod). The typmod generally
has some funny datatype-specific encoding; for varchar and char it
works like this:
-1: max length unknown or unspecified
n>0: max length is n-4 characters
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-08-12 14:22:43 | Re: Regression tests versus the buildfarm environment |
Previous Message | Pavel Stehule | 2010-08-12 13:16:49 | Re: review: psql: edit function, show function commands patch |