Jeff Davis <pg...@j-davis.com> writes: > On the export side, the problem is that the element type (and > dimensionality and maybe hasnull) is an important part of the anyarray > value, but it's not part of the output of anyarray_out(). For new > versions, we can add a scalar function that simply outputs the > information we need. For old versions, we can hack it by parsing the > output of anyarray_send(), which contains the information we need > (binary outputs are under-specified, but I believe they are specified > enough in this case).
Yeah, I was thinking yesterday about pulling the anyarray columns in binary and looking at the header fields. However, I fear there is a showstopper problem: anyarray_send will fail if the element type doesn't have a typsend function, which is entirely possible for user-defined types (and I'm not even sure we've provided them for every type in the core distro). I haven't thought of a good answer to that other than a new backend function. However ... > On the import side, the problem is that there may not be an input > function to go from a 1-D array of text to a 1-D array of any element > type we want. For example, there's no input function that will create a > 1-D array with element type float4[] (that's because Postgres doesn't > really have arrays-of-arrays, it has multi-dimensional arrays). > Instead, don't use the input function, pass each element of the 1-D > text array to the element type's input function (which may be scalar or > not) and then construct a 1-D array out of that with the appropriate > element type (which may be scalar or not). Yup. I had hoped that we could avoid doing any array-munging inside pg_set_attribute_stats, but this array-of-arrays problem seems to mean we have to. In turn, that means that the whole idea of declaring the function inputs as anyarray rather than text[] is probably pointless. And that means that we don't need the sending side to know the element type anyway. So, I apologize for sending us down a useless side path. We may as well stick to the function signature as shown in the v15 patch --- although maybe variadic any is still worthwhile so that an unrecognized field name doesn't need to be a hard error? regards, tom lane