Re: regproc's lack of certainty is dangerous - Mailing list pgsql-hackers

From Tom Lane
Subject Re: regproc's lack of certainty is dangerous
Date
Msg-id 236.1047510236@sss.pgh.pa.us
Whole thread Raw
In response to Re: regproc's lack of certainty is dangerous  (Joe Conway <mail@joeconway.com>)
Responses Re: regproc's lack of certainty is dangerous  (Joe Conway <mail@joeconway.com>)
Re: regproc's lack of certainty is dangerous  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
Joe Conway <mail@joeconway.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


pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: regproc's lack of certainty is dangerous
Next
From: Greg Stark
Date:
Subject: Re: [INTERFACES] Roadmap for FE/BE protocol redesign