Re: Another issue in default-values patch: defaults expanded too soon

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)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 significant amount of work and
> complication, of which enforcing the above check is just a small part.
> I wanted to see a plausible use-case for it before expending that work.

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.

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.

The fundamental problem with polymorphic parameters and default arguments is
that the type of the argument determines the type of the return value. And the
type of the return value can't change within an existing parse tree -- so it
seems to me that barring changing the type of a default argument for a
polymorphic parameter is precisely targeted to the source and should cover all
problems it causes.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!