From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Rod Taylor <rbt(at)zort(dot)ca> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: make "opaque" obsolete |
Date: | 2002-08-20 18:31:24 |
Message-ID: | 19248.1029868284@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Rod Taylor <rbt(at)zort(dot)ca> writes:
>> anyarraytype -- for array_eq, array_dims
> Will this allow generic array iterator functions in the future?
Hm. Not directly; there's still the issue of how to tell what element
type the array is. array_dims doesn't care, and I think that we have
some kluge for array_eq, but in general it'd be a problem for generic
functions.
I had been thinking that as long as we are going to break datafile
compatibility (due to Manfred's tuple-header changes) this would be
a good time to try to clean up the representation of arrays. It's
bothered me for a long while that the array code is not doing alignment
correctly --- it seems not to matter for any standard type, but arrays
of, say, interval are not aligned the way pg_type says they should be.
The reason I bring this up is that if we are changing the internal
representation of arrays, we could add type OID and perhaps typmod to
the array header, thus making an array value interpretable without any
outside info. Then you could actually do something interesting with
a function taking anyarraytype.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-08-20 18:50:00 | Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in |
Previous Message | Rod Taylor | 2002-08-20 18:19:29 | Re: Proposal: make "opaque" obsolete |