Gregory Stark wrote:
Well honestly I don't see a terribly compelling use case for default arguments
altogether. Obviously they're just a programmer convenience and don't really
let anyone do anything they couldn't do without them.
The real payoff comes with name-based paramter lists (the name =
2008/12/17 Robert Haas :
> On Tue, Dec 16, 2008 at 9:18 PM, Tom Lane wrote:
>> "Robert Haas" writes:
>>> I wonder whether the whole architecture is wrong here. Perhaps when a
>>> function is created with N arguments of which M have default values,
>>> we should actually create M entries in pg_pr
On Tue, Dec 16, 2008 at 9:18 PM, Tom Lane wrote:
> "Robert Haas" writes:
>> I wonder whether the whole architecture is wrong here. Perhaps when a
>> function is created with N arguments of which M have default values,
>> we should actually create M entries in pg_proc: one for each possible
>> nu
"Robert Haas" writes:
> I wonder whether the whole architecture is wrong here. Perhaps when a
> function is created with N arguments of which M have default values,
> we should actually create M entries in pg_proc: one for each possible
> number of arguments from N-M up through N.
That's been co
On Tue, Dec 16, 2008 at 3:25 PM, Tom Lane wrote:
> Does anyone think this is either unsurprising or desirable?
That's horrible.
I wonder whether the whole architecture is wrong here. Perhaps when a
function is created with N arguments of which M have default values,
we should actually create M
Gregory Stark writes:
> So it's not like any use case for default polymorphic arguments is going to be
> especially compelling either. But I don't see any reason it'll be any less
> useful for polymorphic arguments than any other type.
Well, the reason it seems funny to me is that the point of a
Tom Lane writes:
> Gregory Stark writes:
>> We could say that changing the type of a default argument for a polymorphic
>> argument isn't allowed just like changing the return value.
>
> The point I was trying to make is that allowing defaults for polymorphic
> args at all is going to cause a ve
Gregory Stark writes:
> We could say that changing the type of a default argument for a polymorphic
> argument isn't allowed just like changing the return value.
The point I was trying to make is that allowing defaults for polymorphic
args at all is going to cause a very significant amount of wor
Tom Lane writes:
> Josh Berkus writes:
>
>> That is, I think we should treat changing the defaults the same as we
>> would changing the number and type of parameters; it kicks off a
>> dependency check and requires a CASCADE.
>
> Dream on ... there is no such facility in Postgres and we are no
Josh Berkus writes:
> Huh? Shouldn't changing a function which a view depends on require a
> rebuild of the view?
There is no such concept as "a rebuild of the view".
> That is, I think we should treat changing the defaults the same as we
> would changing the number and type of parameters; it
Tom Lane wrote:
Consider
create function foo(f1 int, f2 int = 42, f2 int = 43) ...
create view v1 as select foo(11);
In CVS HEAD this gives
regression=# \d v1
View "public.v1"
Column | Type | Modifiers
+-+---
foo| integer |
View definition:
SELECT fo
And while we're on the subject ... as the patch stands, it lets you
provide defaults for polymorphic parameters, as in
regression=# create function eq (f1 anyelement, f2 anyelement default 42)
returns bool as 'select $1 = $2' language sql;
CREATE FUNCTION
regression=# select eq(now(),now());
eq
"David E. Wheeler" writes:
> On Dec 16, 2008, at 10:36 PM, Tom Lane wrote:
>> ... The point here would be to ensure that function replacement
>> couldn't change the parser's decisions about whether a function matches
>> a call or not; which is the case in existing releases, but has been
>> falsifi
On Dec 16, 2008, at 10:36 PM, Tom Lane wrote:
I haven't really thought through the consequences of this, but one
thing
we could consider doing to tamp down the damage is to prohibit
changing
the number of defaultable parameters of an existing function, ie treat
pronargdefaults as not allowed
"David E. Wheeler" writes:
> On Dec 16, 2008, at 10:15 PM, Tom Lane wrote:
>> I'm not too thrilled about it. One thing to consider is that with the
>> default gone, it might be that there is some other function that
>> matches
>> the textual call better than this one. But we can't really chang
On Dec 16, 2008, at 10:15 PM, Tom Lane wrote:
Would the same thing happen for a prepared statement that calls the
function? Or another function?
Prepared statements and functions don't have such a problem, because
they don't have a long-lived parsetree representation. If you change
the defaul
"David E. Wheeler" writes:
> On Dec 16, 2008, at 9:25 PM, Tom Lane wrote:
>> I'm not sure we can do much to fix it, though. It'd probably be
>> possible to have the rewriter or planner insert the default
>> expressions, instead of the parser; but that creates its own issues.
> Would the same t
On Dec 16, 2008, at 9:25 PM, Tom Lane wrote:
Consider
create function foo(f1 int, f2 int = 42, f2 int = 43) ...
create view v1 as select foo(11);
In CVS HEAD this gives
regression=# \d v1
View "public.v1"
Column | Type | Modifiers
+-+---
foo| integer |
Vie
Consider
create function foo(f1 int, f2 int = 42, f2 int = 43) ...
create view v1 as select foo(11);
In CVS HEAD this gives
regression=# \d v1
View "public.v1"
Column | Type | Modifiers
+-+---
foo| integer |
View definition:
SELECT foo(11, 42, 43) AS fo
19 matches
Mail list logo
