From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: regproc's lack of certainty is dangerous |
Date: | 2003-03-12 23:03:56 |
Message-ID: | 236.1047510236@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Joe Conway <mail(at)joeconway(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2003-03-13 01:23:09 | Re: SQL99 ARRAY support proposal |
Previous Message | Joe Conway | 2003-03-12 22:04:07 | Re: regproc's lack of certainty is dangerous |