| 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: | Whole Thread | Raw Message | 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 |