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  (Joe Conway <mail@joeconway.com>)
Re: regproc's lack of certainty is dangerous  (Joe Conway <mail@joeconway.com>)
Список 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 по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: regproc's lack of certainty is dangerous
Следующее
От: Greg Stark
Дата:
Сообщение: Re: [INTERFACES] Roadmap for FE/BE protocol redesign