Re: Array Char/VarChar Size
От | dmp |
---|---|
Тема | Re: Array Char/VarChar Size |
Дата | |
Msg-id | 47C9D461.1000502@ttc-cmc.net обсуждение исходный текст |
Ответ на | Re: Array Char/VarChar Size (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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@ejurka.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 >
В списке pgsql-jdbc по дате отправления: