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
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
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 |
View
David E. Wheeler da...@kineticode.com 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
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
David E. Wheeler da...@kineticode.com 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
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
David E. Wheeler da...@kineticode.com 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
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
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
Josh Berkus j...@agliodbs.com 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
Tom Lane t...@sss.pgh.pa.us writes:
Josh Berkus j...@agliodbs.com 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
Gregory Stark st...@enterprisedb.com 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
Tom Lane t...@sss.pgh.pa.us writes:
Gregory Stark st...@enterprisedb.com 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
Gregory Stark st...@enterprisedb.com 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
On Tue, Dec 16, 2008 at 3:25 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com 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.
On Tue, Dec 16, 2008 at 9:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
2008/12/17 Robert Haas robertmh...@gmail.com:
On Tue, Dec 16, 2008 at 9:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I wonder whether the whole architecture is wrong here. Perhaps when a
function is created with N arguments of which M have default
19 matches
Mail list logo
