2012/11/27 Bruce Momjian <bruce@momjian.us>:
> On Tue, Nov 27, 2012 at 01:59:04AM -0800, Jeff Davis wrote:
>> On Wed, 2012-11-21 at 15:27 +0000, Simon Riggs wrote:
>> > It would be useful if we issued a NOTICE when an ambiguity is
>> > introduced, rather than when using it.
>> >
>> > Like Bison's reporting of reduce conflicts.
>>
>> This brings up a very important point, which is that a lot of the code
>> is frozen in applications yet invisible at DDL time. So we have to be
>> careful that DDL changes have a reasonable impact on the ability to
>> continue to compile and execute the previously-working SQL received from
>> the applications.
>>
>> In other words, as I said in another reply, we want to avoid cases where
>> something seemingly innocuous (like creating a function) causes
>> previously-working SQL to fail due to ambiguity.
>>
>> As Tom said, detecting the ambiguity at DDL time is not easy, so I'm not
>> suggesting that. And I know that creating a function can already cause
>> previously-working SQL to fail. I'm just saying we should be careful of
>> these situations and not make them more likely than necessary.
>
> For me this highlights why looking at how application languages handle
> overloading might not be as relevant --- most language don't have
> possible-conflicting functions being created at run-time like a database
> does. The parallels in how other databases treat overloading is
> relevant.
it is a basic problem - PostgreSQL has unique possibilities -
polymorphic parameters and almost all databases doesn't support
overloading
probably our system is very similar to Haskell
>
> --
> Bruce Momjian <bruce@momjian.us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + It's impossible for everything to be true. +
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
