>> I used to had a customer who needs to have different client and
>> database encoding than the default. That is, a slightly different
>> mapping between Shift-JIS and other database encoding. Due to
>> unfortunate historical reasons, there are several Shift-JIS variants
>> (in addition to the s
Tatsuo Ishii writes:
>> It would only be important to be able to do it like that if different
>> users of the same database had conflicting ideas about what was the
>> correct conversion between client and database encodings. I submit
>> that that's somewhere around epsilon probability, consideri
> It would only be important to be able to do it like that if different
> users of the same database had conflicting ideas about what was the
> correct conversion between client and database encodings. I submit
> that that's somewhere around epsilon probability, considering we have
> not even hear
Noah Misch writes:
> On Wed, Jan 06, 2016 at 11:56:14PM -0500, Tom Lane wrote:
>> Moreover, we have precedent both for this approach being a bad idea
>> and for us changing it without many complaints. We used to have
>> search-path-dependent lookup of default index operator classes.
>> We found o
On Wed, Jan 06, 2016 at 11:56:14PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > On Tue, Jan 05, 2016 at 01:46:51PM -0500, Tom Lane wrote:
> >> I do not see a lot of point in the namespacing of encoding conversions
> >> either. Does anyone really need or use search-path-dependent lookup of
> >>
Noah Misch writes:
> On Tue, Jan 05, 2016 at 01:46:51PM -0500, Tom Lane wrote:
>> I do not see a lot of point in the namespacing of encoding conversions
>> either. Does anyone really need or use search-path-dependent lookup of
>> conversions?
> I have not issued CREATE CONVERSION except to exper
On Tue, Jan 05, 2016 at 01:46:51PM -0500, Tom Lane wrote:
> I do not see a lot of point in the namespacing of encoding conversions
> either. Does anyone really need or use search-path-dependent lookup of
> conversions?
I have not issued CREATE CONVERSION except to experiment, and I have never
wor
I wrote:
> I still think however that search-path-based lookup of default encoding
> conversions is a Bad Idea, and that we only ought to allow one default
> conversion to exist for any pair of encodings.
> I realized that we could implement that without too much trouble by
> redefining pg_convers
I wrote:
> What is the point of pg_conversion.condefault (the flag that says whether
> a conversion is "default")? AFAICS, there is absolutely no way to invoke
> a conversion that is not default, which means we might as well eliminate
> the concept.
> I do not see a lot of point in the namespacin
What is the point of pg_conversion.condefault (the flag that says whether
a conversion is "default")? AFAICS, there is absolutely no way to invoke
a conversion that is not default, which means we might as well eliminate
the concept.
I do not see a lot of point in the namespacing of encoding conve
> What do the columns conforencoding and contoencoding refer to in
> pg_conversion?
>
> How would I convert those numbers to a string encoding name, just using SQL?
>
> Chris
Use pg_encoding_to_char().
--
Tatsuo Ishii
---(end of broadcast)---
TIP
Hi,
What do the columns conforencoding and contoencoding refer to in
pg_conversion?
How would I convert those numbers to a string encoding name, just using SQL?
Chris
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www
12 matches
Mail list logo
