2010/12/12 Florian Pflug <f...@phlo.org>: > On Dec12, 2010, at 00:19 , Pavel Stehule wrote: >> I prefer a table based >> solution, because I don't need a one "unnest", but other preferences >> are valid too. > That's fine with me. > >> I dissatisfied with your design of explicit target type >> via unused value. I think, so we are not a infrastructure for it now >> - from my view is better to use a common type, that is text now. It's >> nothing new - plpgsql use it too. > Sorry, I can't follow you here. Where does plpgsql use text as "common" type?
plpgsql uses only IO casts. So inside assign statement is checked target type and real type. But this checking is late! I did a patch for early conversion to target type (in plan), but this patch was rejected. So actually, there isn't available information about target type in expression - and probably will be - from compatibility reasons. For example: when target variable is int, but you used a numeric constant, then any assignment does a IO cast from num to int. > >> I see one well design of explicit target type based on polymorphic >> types that respect a PostgreSQL fmgr practice: >> >> We have to allow a polymorphic functions without polymorphic >> parameters. These functions shoud be designed to return value in >> "unknown" type format when this function has not outer information. > I don't think "unknown" is the right type for that. As far as I known, > "unknown" is still a textual type, used to have some type to assign to string > literals during parsing when no better type can be inferred. > >> This information can be passed in function context. When function >> context isn't null, then function has to read target type and should >> to return value in target type. Who can fill a function context? It is >> task for executor. And when CAST contains just function call, then we >> can recheck, if function is polymorphic, and if it is, then we can set >> function context to target type, and then we don't need to call a >> conversion function, because polymorphic function must returns data in >> correct format. > The main difficulty is that currently types are assigned in a bottom-up > fashion as far as I know. To make functions with a polymorphic return value, > but without polymorphic arguments work, you need to assign the return type in > a top-down fashion (It depends on where to value *goes*, not where it *comes > from*). That seems like a rather huge change and has the potential to > complicate quite a few other parts, most notably function lookup/resolution. I don't think: a) the place where we don't know a target type is limited only to first outer cast b) I didn't defined polymorphic function without polymorphic parameters (PFWPP) as absolutly undescribed - it returns a "unknown" or "text" in default. There isn't problem to search a this function - and isn't a problem for later work, so this function returns "text", because first outer cast ensure transformation to correct type. c) when function is called without outer cast then it runs too - but there will be one IO cast more. some alchemy with function descriptor ale used now too - when default parameters are used. > > Plus, the general case where type information must bubble up more than one > level seems pretty much intractable, as it'd require a full-blown type > inference algorithm like ML or Haskell. Not a place where we want to go, I > believe. > > The restricted case, on the other hand, brings very little benefit compared > to the dummy-parameter approach. Yeah, "<polymorphic function>()::type" may > look a bit cleaner than "<polymorphic function>(NULL::type)", but thats about > is. It's only assignments in pl/pgsql which really benefit, since you'd be > able to leave out the type completely, writing simply "v_value := > <polymorphic_function>()". Does that really warrant the effort that'd be > involved? > >> Without described functionality we can design a not polymorphic >> function, that can returns unknown type. When similar functionality >> will be implemented, then this function will be changed to >> polymorphic, but from user's perspective, there isn't a change. > I don't really understand why you resist the idea of a dummy parameter so > much. It might not be pretty, but is it bad enough to rectify putting in all > this work? Plus, the whole record-manipulation stuff isn't going to win a > beauty contest anytime soon. But it's better than nothing, so as long as it's > reasonably efficient I think one can live with a few warts on the API. I wrote it. In this case, you don't need to know a value, you have to work with type. So using a typed null isn't intuitive and it isn't nice - for me - too ugly for in general module. I know, so PFWPP functions need a lot of coding without sure result, and it's reason, why I didn't used it and why I use a "text" type. And I have a other reason for - I expect so there is bigger probability to iterate over different type's fields, so coercion to one target type isn't available in one path. Using a more path (like you are showed in code) is relative "high" technique - there is a few developers who can use it and understand. So my design is oriented more to typical programmers who doesn't know a plpgsql implementation details. These people can use a some strange solution based on dynamic sql and are happy, so they has a workable code. It's question what design is more useful - I don't know. But I am strong against to add some strange API to pg. Regards Pavel > > best regards, > Florian Pflug > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
