Re: MySQL search query is not executing in Postgres DB
От | Jeff Davis |
---|---|
Тема | Re: MySQL search query is not executing in Postgres DB |
Дата | |
Msg-id | 1355205584.22087.13.camel@jdavis обсуждение исходный текст |
Ответ на | Re: MySQL search query is not executing in Postgres DB (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: MySQL search query is not executing in Postgres DB
Re: MySQL search query is not executing in Postgres DB |
Список | pgsql-hackers |
On Mon, 2012-12-10 at 14:07 -0500, Robert Haas wrote: > And we not only don't give them the behavior they want; we > don't even have a meaningful way to give the option of opting into > that behavior at initdb or create-database time. I strongly object to offering options that change the language in such a substantial way. initdb-time options still mean that we are essentially dividing our language, and therefore the applications that support postgres, in half (or worse). One of the things I really like about postgres is that we haven't forked the language with a million options like mysql has. I don't even like the fact that we have a GUC to control the output format of a BYTEA. For every developer who says "wow, that mysql query just worked without modification" there is another one who says "oh, I forgot to test with option XYZ... postgres is too complex to support, I'm going to drop it from the list of supported databases". I still don't see a compelling reason why opting out of overloading on a per-function basis won't work. Your objections seemed fairly minor in comparison to how strongly you are advocating this use case. In particular, I didn't get a response to: http://archives.postgresql.org/message-id/1354055056.1766.50.camel@sussancws0025 For what it's worth, I'm glad that people like you are pushing on these usability issues, because it can be hard for insiders to see them sometimes. Regards,Jeff Davis
В списке pgsql-hackers по дате отправления: