Re: RFC for adding typmods to functions - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: RFC for adding typmods to functions |
Date | |
Msg-id | 603c8f070911171613n60e36671w73aa748fa679a74b@mail.gmail.com Whole thread Raw |
In response to | Re: RFC for adding typmods to functions (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: RFC for adding typmods to functions
Re: RFC for adding typmods to functions |
List | pgsql-hackers |
On Tue, Nov 17, 2009 at 6:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> Apart from all these it's not clear to me what the major benefits of >> doing this would be. I'd like an explanation of that to start with. > > Well, aside from the issue about making "anyelement" more powerful > (which could be done in other ways), I can think of: > > If we don't start down this path then we are never going to satisfy the > spec's expectations about type modifiers (the varchar concatenation > example among others). The given patch doesn't do that or even come > close, but it's a necessary prelude. > > More generally, people have complained in the past about typmods being > red-headed stepchildren in the type system. At present, since the > majority of expression forms throw away typmod information, there's > not much hope of treating typmod on the same level as type proper. > (If you look at the history of the expression-tree code you'll notice > that we've gradually propagated typmods into more and more places. > Associating a typmod with function results is the last major holdout.) > > I'm not sure that these points fully justify the work involved, but > it certainly seems to be a logical avenue of development if we can > agree on the semantics. There's something a little weird about the whole typmod concept. In the case of varchar(n) and numeric(x,y), it seems as though it's perhaps intended to allow the database to optimize by limiting the amount of on-disk storage that needs to be set aside for those values.Or you could alternatively view it as a type of constraint,like "the length of this string is at most n characters". The thing is, in most modern programming languages, this type of information isn't part of the type system at all. You have a type called string, and it represents a string of any length at all (of course, in C strings are fixed size-arrays, but that's more the exception than the rule, and C is a much lower-level language than SQL). Typically, details like the maximum number of characters in the string or the desired scale and precision of a numeric value aren't dealt with until you try to print the value out. So I guess really can't get worked up about the idea of propagating this information through the type system. Even suppose we eventually take the steps you suggesting and make it so that varchar(30) || varchar(40) yields varchar(70). What good is that? Why would anyone care? What would actually be really nice is the ability to have parameterized types (like list-of-<some type>, unordered-set-of-<type>, hash-with-keys-of-<some type>-and-values-of-<some type>, function-taking-arguments-of-<various types>-returning-<some type>) which would let us do all kinds of neat things - but I don't see how improving support for typmods gets us any closer to that. ...Robert
pgsql-hackers by date: