Re: MySQL search query is not executing in Postgres DB
От | Bruce Momjian |
---|---|
Тема | Re: MySQL search query is not executing in Postgres DB |
Дата | |
Msg-id | 20121127164037.GA1820@momjian.us обсуждение исходный текст |
Ответ на | Re: MySQL search query is not executing in Postgres DB (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: MySQL search query is not executing in Postgres DB
|
Список | pgsql-hackers |
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. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: