Re: actualised funcs typmod patch
От | Pavel Stehule |
---|---|
Тема | Re: actualised funcs typmod patch |
Дата | |
Msg-id | 162867790911170717kb4ac57fi83202a917c981bb9@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: actualised funcs typmod patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: actualised funcs typmod patch
|
Список | pgsql-hackers |
2009/11/17 Tom Lane <tgl@sss.pgh.pa.us>: > Dimitri Fontaine <dfontaine@hi-media.com> writes: >> The idea to add support for typmods in function signatures came from the >> need to have more than one anyelement at a time in a function, and Pavel >> proposed that we spell that anyelement(0) and anyelement(1) e.g. > >> Is that how we want to solve it? > > TBD, really. It was one possibility. > >> Now, whatever the answer to that is, I guess the patch still has >> interest in itself for being able to have a function f(x numeric(10,4)) >> for example. Right? > > I think there are a large number of definitional details that would have > to be considered to determine exactly what that means or how things > should behave, and I'm quite distressed that Pavel seems to have taken a > code-first-think-later approach to this patch. > > The main stumbling block that we've run into in previous discussions is > that it's not tremendously useful to propagate typmod unless you have > some method for determining the appropriate *output* typmod for a > function; and just declaring it with a fixed typmod doesn't cover > anywhere near enough use-cases. A simple example is that concat'ing > varchar(20) and varchar(22) ought to yield varchar(42) --- in fact, that > is required by SQL spec --- but there's no possible way of determining > that without exceedingly type-specific and function-specific knowledge. > I recall some discussion of attaching parse-time "helper" functions to > every function that would embody such knowledge, but nobody particularly > wanted to follow through on that. typmod is applying on input and output too. When I working with varchar(20) inside some custom function, then using typmod in definition (input, result) eliminate some useless typmod conversions. Without typmods for result - non sql functions are blackbox - no body knows, what will be result. Without typmodes for input function cannot trust to outside, and have to recheck input. I thing so minimally for plpgsql programming (typmod support has a benefit), sure, only when people use typmode based types. > > If the only immediate benefit we'd get is multiple anyelement types, > I think we'd be much better advised to just create a few separate > types for that. Function typmods are a big can of worms and we should > not lock ourselves into a half-baked solution. > When I started work on typmod support, my motivation was only a multiple anyelement types. Now, I thing, so typmodes are more important than parametrized polymorphic type. Now, PL are dynamic with minimal static checks. Step by step the static checks are richer. I could to imagine future warning like "declared varchar(40), but potential content is varchar(50)". These controls are not possible without using typmodes in function (explicitly declared). > regards, tom lane >
В списке pgsql-hackers по дате отправления: