"Martijn van Oosterhout" <kleptog@svana.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
conversionon the field names used for the hash keys. For historical reasons it defaults to '"NAME"' but it is
recommendedto 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!