Re: regproc's lack of certainty is dangerous
От | Tom Lane |
---|---|
Тема | Re: regproc's lack of certainty is dangerous |
Дата | |
Msg-id | 236.1047510236@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: regproc's lack of certainty is dangerous (Joe Conway <mail@joeconway.com>) |
Ответы |
Re: regproc's lack of certainty is dangerous
Re: regproc's lack of certainty is dangerous |
Список | pgsql-hackers |
Joe Conway <mail@joeconway.com> 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? > ISTM that the best (if not the only feasible) approach is using array of > bytea to hold the internal representation of the type. I'd like "select * from pg_statistic" to still produce readable output whenever possible, though. The bytea approach falls down badly on that score, so I don't want to resort to it except where I absolutely must. 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 investigations into polymorphic array functions, perhaps. Maybe "anyarray" shouldn't be quite so pseudo a pseudotype? regards, tom lane
В списке pgsql-hackers по дате отправления: