Re: Statistics Import and Export
От | Corey Huinker |
---|---|
Тема | Re: Statistics Import and Export |
Дата | |
Msg-id | CADkLM=dFrHKkMeBKwFJz4FsC0vTDmjoc3iy-+cfL=XKBAY5UjA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Statistics Import and Export (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Statistics Import and Export
|
Список | pgsql-hackers |
Jeff suggested looking at anyarray_send as a way of extracting the type, and with some extra twiddling we can get and cast the type. However, some of the ANYARRAYs have element types that are themselves arrays, and near as I can tell, such a construct is not expressible in SQL. So, rather than getting an anyarray of an array type, you instead get an array of one higher dimension. Like so:
# select schemaname, tablename, attname,
substring(substring(anyarray_send(histogram_bounds) from 9 for 4)::text,2)::bit(32)::integer::regtype,
substring(substring(anyarray_send(histogram_bounds::text::text[][]) from 9 for 4)::text,2)::bit(32)::integer::regtype
from pg_stats where histogram_bounds is not null
and tablename = 'pg_proc' and attname = 'proargnames' ;
schemaname | tablename | attname | substring | substring
------------+-----------+-------------+-----------+-----------
pg_catalog | pg_proc | proargnames | text[] | text
Luckily, passing in such a value would have done all of the element typechecking for us, so we would just move the data to an array of one less dimension typed elem[]. If there's an easy way to do that, I don't know of it.
What remains is just checking the input types against the expected type of the array, stepping down the dimension if need be, and skipping if the type doesn't meet expectations.
В списке pgsql-hackers по дате отправления: