On Fri, Mar 19, 2004 at 05:28:42PM -0000, Andy Hassall wrote:
>
> > > Attached is the patch for adding ora_can_unicode.
> >
> > Thanks. Is the /UTF/ regex safe against false matches?
>
> I believe so - I checked the values in v$nls_valid_values and only the
> Unicode-based character sets had 'UTF' in them.
>
> SQL> select value
> 2 from v$nls_valid_values
> 3 where parameter = 'CHARACTERSET'
> 4 and value like '%UTF%';
>
> VALUE
> ------------------------
> AL24UTFFSS
> UTF8
> UTFE
> AL32UTF8
> AL16UTF16
>
> Or would you prefer the character sets to be matched exactly against a
> list? I can gather the values from 8i, 9i and 10g if required.
No, /UTF/ is fine. Thanks for the list.
> > I was about to apply it when I started wondering if it could be one
> > with one db query instead of two. Then I started wondering if it
> > might be better to add a ora_nls_parameters() method using:
> >
> > $dbh->{ora_nls_parameters} = $dbh->selectall_hashref(q{
> > SELECT parameter, value FROM v$nls_parameters
> > });
> >
> > and then implement ora_can_unicode() in terms of
> > $dbh->{ora_nls_parameters}
> >
> > If that sounds good to you could you rework it that way?
>
> OK - will do.
>
> I don't think they can be safely cached - some of them are alterable at
> session level (e.g. nls_date_format), whereas it was a safe bet that
> database character sets wouldn't change during the life of a session
> (although not impossible).
ora_nls_parameters() could default to caching and take a param to
force an update of the cache.
Tim.
