David Fetter <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org