From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Peter Eisentraut" <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP: default values for function parameters |
Date: | 2008-11-30 20:13:50 |
Message-ID: | 162867790811301213u1e66bd01hafd412f28e58ce97@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2008/11/30 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> 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'll prepare new patch with this change.
>
> Yes. I think that the argument for allowing parameter names in commands
> like ALTER FUNCTION is that the user might consider them part of the
> function's identity. This can hardly be claimed for default values.
>
> Also, there's a third possibility: we could revert the decision to allow
> pg_dump to depend on pg_get_function_arguments in the first place. That
> was really the lazy man's approach to begin with. The more we allow
> pg_dump to depend on backend functions that work in a SnapshotNow world,
> the more risk we have of producing inconsistent dumps.
I don't understand well. Transactions is spanish village for me. So
there will be some finalizing necessary from You or Peter.
Regards
Pavel Stehule
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2008-11-30 21:03:29 | Re: pgsql: Remove inappropriate memory context switch in |
Previous Message | David Rowley | 2008-11-30 19:11:10 | Re: Windowing Function Patch Review -> Standard Conformance |