`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:

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)

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`

---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])