Re: TODO Item: Consider allowing control of upper/lower case folding of unquoted, identifiers

"Martijn van Oosterhout" <kleptog(at)svana(dot)org> writes:

> On Fri, Mar 28, 2008 at 03:30:21AM +1100, Russell Smith wrote:
>> 3. the client needs to know what quote rules are in place. (libpq:
>> PQfname, PQfnumber)
>
> The question I want to see answered, is how something like DBD::Pg will
> handle this. If I wrote code like this in Perl:
>
> my %hash = $res->get_row_as_hash();
> print $hash{mycolumn};
>
> Will this change break my code? Perl hashes are case-sensetive, you
> can't change that. And it seems impossibly complex to fix the above
> code to work with all the possible combinations... Which starts leading
> you down the path of folding in some places and not others, which is
> madness.

Well, DBI already has to deal with this anyways because it tries to provide a
database-independent interface. So you can instruct DBI to upcase, downcase,
or leave the identifiers as the database provides them by setting this
property on your database connection:

"FetchHashKeyName" (string, inherited)

The "FetchHashKeyName" attribute is used to specify whether the
fetchrow_hashref() method should perform case conversion on the field
names used for the hash keys. For historical reasons it defaults to
'"NAME"' but it is recommended to set it to '"NAME_lc"' (convert to lower
case) or '"NAME_uc"' (convert to upper case) according to your preference.
It can only be set for driver and database handles. For statement handles
the value is frozen when prepare() is called.

So if you've always been using unquoted identifiers you can set
FetchHashKeyName to NAME_lc and it would continue to work. If you've been
using a mixture of quoted and unquoted identifiers things would be trickier
though.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!