Re: MySQL search query is not executing in Postgres DB

I agree with Jeff.

Options that change the language at initdb or create-database time just fragment
the language.

It is best to just have 1 language where options are providable either
dynamically per connection or otherwise lexically, so that then they are really
just shorthands for the current local usage, and the language as a whole is the
same.

That also means you can have example code out there and know it will work on any
Postgres install, invariant of static global options. If language modifiers are
local or lexical, then any example code presumably would include the switches to
turn them on for that example.

That all being said, I also think it is best to explicitly overload operators
with extra parameter types, such as defining another operator with the signature
of (Nunber,String) with the same base name as string catenation, rather than
making numbers implicitly stringify. But I can also accept implicit
stringification / language behavior changes if it is a lexical/temporary effect
that the same user is still explicitly turning on.

-- Darren Duncan

Jeff Davis wrote:
> 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