> > 4. What about functions whose output typmod should depend on the input > typmod(s)? I mentioned earlier the example that concatenation of > varchar(M) and varchar(N) should produce varchar(M+N). We could possibly > punt on this for the time being; supporting only fixed output typmods for > now doesn't obviously foreclose us from adding support for computed > typmods later. However there is still one nasty case that we cannot > push off till later: given a function that takes and returns a polymorphic > type such as anyelement, and an actual argument with a typmod (eg > numeric(2)), is the result numeric(2) or just numeric? As things stand > we would have little choice but to say the latter, because we don't know > what the function might do with the value, and there are too many real > cases where the result might not have the same typmod. But there are > also a lot of cases where you *would* wish that it has the same typmod, > and this patch raises the stakes for throwing away typmods mid-expression. > Is this okay, and if not what could we do about it?
polymorphic functions should to ignore typmnod :( - with current syntax - on output. I don't believe so we are able to find any mechanism usable for non typmod types and typmod types. We could to enhance syntax for using typmod from parameters - maybe some flag like STRICT, maybe TYPMOD? Regards Pavel > > Unless we have consensus on all of these points I don't think we should > proceed with the patch. Comments? > > regards, tom lane > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
