From: | dmp <danap(at)ttc-cmc(dot)net> |
---|---|
To: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Array Char/VarChar Size |
Date: | 2008-03-01 22:10:41 |
Message-ID: | 47C9D461.1000502@ttc-cmc.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Mr. Lane,
I used your suggestion and it works nicely. From a client perspective
I would prefer to see support for this type of information from the
JDBC for longevity, robustness, and isolation purposes. Currently
the JDBC returns only NULLs.
Again thanks guys, I appreciate the help.
danap.
>Kris Jurka <books(at)ejurka(dot)com> writes:
>
>
>>> Multi-dimensional array information is not stored. Every array type may
>>> be any number of dimensions. The precision information is not available
>>> in the information_schema, but it is available in the system catalog
>>> tables. See pg_attribute.atttypmod, but it does require some decoding.
>>
>>
>
>Rather than embedding knowledge of typmod encoding in client-side code,
>may I suggest using the format_type function? For example
>
>select format_type(atttypid, atttypmod) from pg_attribute where
>attrelid = 'my_table'::regclass and attname = 'my_column';
>
>This will give you back something reasonably standardized, like
>"character varying(42)[]". You'll still need a bit of logic to
>extract what you want, but it seems much less likely to break.
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | dmp | 2008-03-01 22:32:46 | Re: Summer of Code Java? |
Previous Message | Tom Lane | 2008-03-01 18:33:56 | Re: PreparedStatement cache and dynamic queries |