Обсуждение: Runtime Config Option for identifier case preservation

Поиск
Список
Период
Сортировка

Runtime Config Option for identifier case preservation

От
Michael W Mitton
Дата:
Attached is a patch to allow the user to change the behavior of postgres with
reguards to case sensitivity on unquoted identifiers.  This does not change
the default behavior of converting unquoted identifiers to lowercase, but
does allow (for instance, and I'm absolutly -not- pulling from personal
experience here <g>) a large project to run under postgres that did run under
MySQL a whole bunch easier.

for example, these two SQL statements sets are identical
set parser-ignore-case = false;
select "Address_id" from "Address";

set parser-ignore-case = true;
select Address_id from Address;

Вложения

Re: Runtime Config Option for identifier case preservation

От
Michael W Mitton
Дата:
Opps!  I have my logic backwards below.  Those two SQL sets should be
set parser-ignore-case = true;
select "Address_id" from "Address";

set parser-ignore-case = false;
select Address_id from Address;


On Friday 14 January 2005 02:51 pm, Michael W Mitton wrote:
> Attached is a patch to allow the user to change the behavior of postgres
> with reguards to case sensitivity on unquoted identifiers.  This does not
> change the default behavior of converting unquoted identifiers to
> lowercase, but does allow (for instance, and I'm absolutly -not- pulling
> from personal experience here <g>) a large project to run under postgres
> that did run under MySQL a whole bunch easier.
>
> for example, these two SQL statements sets are identical
> set parser-ignore-case = false;
> select "Address_id" from "Address";
>
> set parser-ignore-case = true;
> select Address_id from Address;

Re: Runtime Config Option for identifier case preservation

От
Tom Lane
Дата:
Michael W Mitton <mmitton@ssi-c.com> writes:
> Attached is a patch to allow the user to change the behavior of postgres with
> reguards to case sensitivity on unquoted identifiers.

This patch has zero chance of being accepted.  Please read the past
discussions in the pgsql-hackers' archives to find out why it's not
nearly that easy.

            regards, tom lane