Re: WIP: default values for function parameters

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
>

In response to

Browse pgsql-hackers by date

  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