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 > ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq