From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: regproc's lack of certainty is dangerous |
Date: | 2003-03-13 02:09:55 |
Message-ID: | 3E6FE873.5020808@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Barry Lind | 2003-03-13 02:27:57 | Re: Roadmap for FE/BE protocol redesign |
Previous Message | Dave Cramer | 2003-03-13 02:09:05 | Re: Roadmap for FE/BE protocol redesign |