David Fetter <david@fetter.org> writes:
> After several rounds of patches, it appears that it might be easier to
> create a new typtype entry, which I'll tentatively call 'a' because it
> seems a little fragile and a lot inelegant and hard to maintain to
> have typtype='c' and typrelid=InvalidOid mean, "this is an array of
> complex types."
Uh, wouldn't it be typtype = 'c' and typelem != 0 ?
> I'd like to see about making this new typtype
> available for arrays of DOMAINs eventually, but that's not a
> requirement right this instant.
Hmm. It might not be a bad idea to switch to 'a' for arrays over
regular scalar types too. Right now we have some klugy rules involving
looking at typlen to decide whether an array type is a normal array.
(There are also some special subscriptable types like name and point,
which should continue to not use 'a' because they are not general
purpose arrays. So the 'a' marker wouldn't be entirely redundant with
typelem being nonzero, rather checking for 'a' would replace the places
where we test both typelem and typlen.) OTOH this is a lot of hacking
for something that I'm not convinced is really needed.
Anyway, the point is that I dislike the idea of doing arrays for complex
types differently from those for scalars --- either both should use a
new typtype, or neither. If you try to do it differently then you'll
have more complexity, not less, since there are a lot of places that
shouldn't need to care. get_element_type() is an example.
> What parts of the code would need a once-over?
A lot :-( ... probably every place that touches typtype or typelem would
need at least a look. It'd be a good idea to take the opportunity to
start using macros for the values of typtype, as we do for relkind but
for some reason never adopted for typtype.
regards, tom lane