2008/12/18 Pavel Stehule <pavel.steh...@gmail.com>: > 2008/12/18 Tom Lane <t...@sss.pgh.pa.us>: >> "Pavel Stehule" <pavel.steh...@gmail.com> writes: >>> 2008/12/17 Tom Lane <t...@sss.pgh.pa.us>: >>>> Experimenting with the revised code, I found a curious case that might >>>> be worth worrying about. Consider the example that started all this: >> >>> do you remember on request for using "default" keyword in funccall? >>> This should be solution. In view, you don't store select foo(11), but >>> you have to store select foo(11, default, default). >> >> Seems pretty ugly; keep in mind you'd be looking at that notation >> constantly (in \d, EXPLAIN, etc), not just in dumps. >> > > yes, it's not perfect - and I have to agree, prepared statements, > views should by (and it is) problem. I didn't expect it. On second > hand (practical view) most of functions with defaults or variadic will > not be overloaded (it's not argument), so we could be more strict in > checking.
some primitive idea - we could to disallow defaults params for views. Pavel > > regards > Pavel Stehule > >> I think the most conservative thing to do is to treat varying numbers of >> defaults as ambiguous for now. We can relax that later without breaking >> working code, but we couldn't go the other way if something else comes >> up. >> >> 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