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
|
Список | 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 по дате отправления: