Re: regproc's lack of certainty is dangerous

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: regproc's lack of certainty is dangerous
Дата
Msg-id 3E6FE873.5020808@joeconway.com
обсуждение исходный текст
Ответ на Re: regproc's lack of certainty is dangerous  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: regproc's lack of certainty is dangerous  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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
> investigations into polymorphic array functions, perhaps.
> 
> Maybe "anyarray" shouldn't be quite so pseudo a pseudotype?
> 

More on this idea; here is a simple experiment:

regression=# update pg_type set typtype = 'b', typinput = 'array_in', 
typoutput = 'array_out' where oid = 2277;
UPDATE 1
regression=# create table bar(f1 int, f2 anyarray);
CREATE TABLE
regression=# insert into bar values (1,'{1,2}'::integer[]);
INSERT 744428 1
regression=# insert into bar values (2,'{a,b}'::text[]);
INSERT 744429 1
regression=# select * from bar; f1 |  f2
----+-------  1 | {1,2}  2 | {a,b}
(2 rows)

Interesting ... but then there is:
regression=# select f1, f2[2] from bar;
ERROR:  transformArraySubscripts: type anyarray is not an array

A bit more to do I guess.

Joe



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dave Cramer
Дата:
Сообщение: Re: Roadmap for FE/BE protocol redesign
Следующее
От: "Ron Mayer"
Дата:
Сообщение: Re: Case insensitivity, and option?