From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "Peter Eisentraut" <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: WIP: default values for function parameters |
Date: | 2008-12-01 13:40:09 |
Message-ID: | 162867790812010540i69d3cc46p6d2570f45585f456@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2008/11/30 Peter Eisentraut <peter_e(at)gmx(dot)net>:
> On Thursday 27 November 2008 00:14:19 Pavel Stehule wrote:
>> I am sending actualized versions - I accepted Tom's comments - default
>> expressions are serialised List stored in text field.
>
> OK, this is looking pretty good.
>
> There is a structural problem that we need to address. With your patch,
> pg_dump produces something like this:
>
> CREATE FUNCTION foo(a integer = 1, b integer = 2, c integer = 3) RETURNS
> integer
> LANGUAGE sql
> AS $_$ SELECT $1 + $2 + $3; $_$;
>
> ALTER FUNCTION public.foo(a integer = 1, b integer = 2, c integer = 3) OWNER
> TO peter;
>
>
> The second command is rejected because default values are only accepted in
> CREATE FUNCTION.
>
> There are two ways to fix this, both having some validity:
>
> 1. We create a second version of pg_get_function_arguments() that produces
> arguments without default values decoration. This is probably the
> technically sound thing to do.
I did it. new version is attached
Regards
Pavel Stehule
>
> 2. We accept the default values specification and ignore it silently. Note
> that we already silently ignore the argument names. ALTER FUNCTION foo(a
> int, b int) will also act on a function defined as foo(x int, y int).
>
> Comments?
>
Attachment | Content-Type | Size |
---|---|---|
defaults0112.diff.gz | application/x-gzip | 97.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2008-12-01 14:40:43 | Re: Simple postgresql.conf wizard |
Previous Message | Heikki Linnakangas | 2008-12-01 12:08:07 | New to_timestamp implementation is pretty strict |