I wrote:
>> I think that we can actually get away (from an implementation point of
>> view) with a column containing arrays of different base types; array_out
>> will still work AFAIR. It's an interesting question though how such a
>> column could reasonably be declared. This ties into your recen
Tom Lane wrote:
I think that we can actually get away (from an implementation point of
view) with a column containing arrays of different base types; array_out
will still work AFAIR. It's an interesting question though how such a
column could reasonably be declared. This ties into your recent
inv
Tom Lane wrote:
I think that we can actually get away (from an implementation point of
view) with a column containing arrays of different base types; array_out
will still work AFAIR. It's an interesting question though how such a
column could reasonably be declared. This ties into your recent
inv
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I am not sure what to do about columns that
>> have datatypes without matching array types, though (that would include
>> array columns and domains, IIRC). Maybe use array of bytea to hold the
>> internal representation of the type?
> IS
Tom Lane wrote:
Another approach is to try to fix pg_statistic to avoid the problem by
not doing I/O conversions. For scalar datatypes (those that have
associated array types) it'd be probably be feasible to store the
histogram and most-common-value arrays as arrays of the datatype itself,
not arr
Deepak Bhole of Red Hat just pointed out to me a failure that he got
after some 7.3 stress testing:
> [ "[EMAIL PROTECTED]&*()''| \final_db\n,.;:'" ]=# SELECT n.nspname, p.proname,
> o.oprcode::oid FROM pg_operator o, pg_proc p, pg_namespace n WHERE
> o.oid=270447::oid AND p.oid=o.oprcode::oid AND
