On Thu, Aug 03, 2006 at 05:04:47PM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > On Thu, Aug 03, 2006 at 04:18:53PM -0400, Tom Lane wrote:
> >> I think we could legislate that the stored typmod is the same as what
> >> the user sees (and can't be negative). The fact that it's different
> >> for some of the built-in types is a historical artifact that I'd love
> >> to get rid of.
>
> > But that makes NUMERIC(x,y) impossible to represent.
>
> Well, we have to special-case INTERVAL anyway (because its cramming some
> truly bizarre things into typmod), and it wouldn't bother me too much to
> special-case NUMERIC as well.
>
> Another option is to agree on some simple rule for cramming two values
> into one typmod, like first one in the low half and second in the high
> half, and then user types could have either one or two typmod values ---
> but I can imagine some pretty bizarre behavior if the type is expecting
> one value and you enter two or vice versa. NUMERIC can finesse this
> because the default for scale is zero, but in the general case that
> wouldn't work so well.
>
> Does anyone have examples of real user-defined types that would need two
> fields? If not it may not be worth spending time on.
I can think of histograms as a data type which may take more than one argument,
maybe even an array for boundary information. I think the direction *in the
long term* should be to allow multiple arguments (as a ROW type?) and other
base or complex types as arguments. The value would be a type itself and
the datatype must do the right thing regarding it. This may not be practical
for short-term, but would open up initialization parameters for user-defined
typed.
--elein
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>
