Postgres Pro
Downloads
Home   >   mailing lists

Thread: Composite Type with Domain

Composite Type with Domain

From
维 姜
Date:
# pg8.1.3

=> CREATE DOMAIN d_1 integer CHECK (VALUE < 10);
=> CREATE TYPE t_1 AS (m d_1);
=> SELECT '(100)':: t_1; t_1
-------(100)
(1 row)

=> SELECT row(100):: t_1;
错误:  域 d_1 的值违反了检查约束 "d_1_check"


=> \encoding ISO_8859_1
=> SELECT row(100):: t_1;
server closed the connection unexpectedly       This probably means the server terminated abnormally       before or
whileprocessing the request. 
The connection to the server was lost. Attempting reset: Failed.

Re: Composite Type with Domain

From
Tom Lane
Date:
维 姜 <jw.pgsql@sduept.com> writes:
> => \encoding ISO_8859_1
> => SELECT row(100):: t_1;
> server closed the connection unexpectedly

Works for me:

regression=# SELECT row(100):: t_1;
ERROR:  value for domain d_1 violates check constraint "d_1_check"
regression=# \encoding ISO_8859_1
regression=# SELECT row(100):: t_1;
ERROR:  value for domain d_1 violates check constraint "d_1_check"

Please provide more details, like your locale and encoding settings.
        regards, tom lane

Re: Composite Type with Domain

From
JiangWei
Date:
* BUG #1:              => SELECT '(100)':: t_1;          t_1       -------        (100)       (1 row)
-------------------------------------------------------------------
     * BUG #2:                            => \encoding       UTF8       => show server_encoding ;       server_encoding
     -----------------       UTF8                                   => \encoding ISO_8859_1       => SELECT row(100)::
t_1;      server closed the connection unexpectedly               This probably means the server terminated abnormally
            before or while processing the request.       The connection to the server was lost. Attempting reset:
Failed             [jw@dell ~]$ locale       LANG=zh_CN.UTF-8       LC_CTYPE="zh_CN.UTF-8"
LC_NUMERIC="zh_CN.UTF-8"      LC_TIME="zh_CN.UTF-8"       LC_COLLATE="zh_CN.UTF-8"       LC_MONETARY="zh_CN.UTF-8"
LC_MESSAGES="zh_CN.UTF-8"       LC_PAPER="zh_CN.UTF-8"       LC_NAME="zh_CN.UTF-8"       LC_ADDRESS="zh_CN.UTF-8"
LC_TELEPHONE="zh_CN.UTF-8"      LC_MEASUREMENT="zh_CN.UTF-8"       LC_IDENTIFICATION="zh_CN.UTF-8"       LC_ALL= 



在 2006-04-04二的 01:46 -0400，Tom Lane写道：
> 维 姜 <jw.pgsql@sduept.com> writes:
> > => \encoding ISO_8859_1
> > => SELECT row(100):: t_1;
> > server closed the connection unexpectedly
>
> Works for me:
>
> regression=# SELECT row(100):: t_1;
> ERROR:  value for domain d_1 violates check constraint "d_1_check"
> regression=# \encoding ISO_8859_1
> regression=# SELECT row(100):: t_1;
> ERROR:  value for domain d_1 violates check constraint "d_1_check"
>
> Please provide more details, like your locale and encoding settings.
>
>             regards, tom lane
>

NLS vs error processing, again (was Re: Composite Type with Domain)

From
Tom Lane
Date:
JiangWei <jw.pgsql@sduept.com> writes:
>         LANG=zh_CN.UTF-8
> [ set client_encoding to LATIN1 and provoke an error ]

OK, I can reproduce the crash after initdb'ing with that LANG setting
(in an nls-enabled build).  The postmaster log fills with a whole lot
of occurrences of

警告:  忽略不能转换的 UTF-8 字符 0x00e9
警告:  忽略不能转换的 UTF-8 字符 0x00e8
警告:  忽略不能转换的 UTF-8 字符 0x00e8
警告:  忽略不能转换的 UTF-8 字符 0x00e8
比致命错误还过分的错误:  ERRORDATA_STACK_SIZE exceeded

Tracing through the dump shows that the error-handling code is
recursively producing this warning while trying to translate the word
WARNING to LATIN1.  The zh_CN.po file shows the translation as

#: utils/error/elog.c:1909
msgid "WARNING"
msgstr "¾¯¸æ"

(which apparently is GB2312?) and what's actually getting passed to
utf8_to_iso8859_1() is

(gdb) x/6o str
0x8b89d8:       0350    0255    0246    0345    0221    0212

I have no idea if this is a correct UTF8 transliteration of the GB2312
phrase --- can anyone confirm?  But anyway, if this is Chinese then it's
hardly surprising that there would be no LATIN1 equivalent.  And then
trying to report the problem gets us into a new instance of the same
problem.  Even the code that's supposed to stop error recursion doesn't
get us out of it.

It seems to me that there basically is no graceful solution to this sort
of mismatch.  It might be possible to kluge things so that we disable
NLS once we've recursed too many times in error processing, but that's
surely pretty ugly.  What would be a lot more user-friendly would be to
refuse the attempt to set client_encoding to something that can't handle
our error message encoding, but I don't know what a reasonable set of
restrictions would be.

Comments?

            regards, tom lane

Re: NLS vs error processing, again (was Re: Composite Type

From
Euler Taveira de Oliveira
Date:
Tom Lane wrote:

>It seems to me that there basically is no graceful solution to this sort
>of mismatch.  It might be possible to kluge things so that we disable
>NLS once we've recursed too many times in error processing, but that's
>surely pretty ugly.  What would be a lot more user-friendly would be to
>refuse the attempt to set client_encoding to something that can't handle
>our error message encoding, but I don't know what a reasonable set of
>restrictions would be.
>
>
>
Maybe it's the time to convert all PO files to UTF-8. I'm in process to
convert pt_BR ones.


--
Euler Taveira de Oliveira

Re: NLS vs error processing, again (was Re: Composite Type with Domain)

From
Tom Lane
Date:
Euler Taveira de Oliveira <euler@timbira.com> writes:
> Tom Lane wrote:
>> It seems to me that there basically is no graceful solution to this sort
>> of mismatch.  It might be possible to kluge things so that we disable
>> NLS once we've recursed too many times in error processing, but that's
>> surely pretty ugly.  What would be a lot more user-friendly would be to
>> refuse the attempt to set client_encoding to something that can't handle
>> our error message encoding, but I don't know what a reasonable set of
>> restrictions would be.

> Maybe it's the time to convert all PO files to UTF-8. I'm in process to
> convert pt_BR ones.

What does that have to do with it?

            regards, tom lane

Re: NLS vs error processing, again

From
Tom Lane
Date:
Tatsuo Ishii <ishii@sraoss.co.jp> writes:
> As fas as looking into utils/mb/Unicode/euc_cn_to_utf8.map, the
> translation above seems to be correct. BTW, who does the translation
> from EUC-CN to UTF-8? Maybe gettext()?

I'm far from an expert on this, but the gettext documentation indicates
that it tries to translate the .po file contents into whatever encoding
is implied by LC_CTYPE.  The fact that the string passed to
utf8_to_iso8859_1 is not identical to the .po file contents indicates
that gettext is doing *something*.  I'm a bit worried that this
translation could be out of step with what we will expect the
server_encoding to be --- but there's not any immediate evidence of
that.

Anyway, the real problem seems to be what to do if translation of an
error message to the client_encoding fails.  That's clearly a risk even
if gettext has behaved perfectly.

            regards, tom lane

Re: NLS vs error processing, again (was Re: Composite Type

From
Alvaro Herrera
Date:
Euler Taveira de Oliveira wrote:
> Tom Lane wrote:
>
> >It seems to me that there basically is no graceful solution to this sort
> >of mismatch.  It might be possible to kluge things so that we disable
> >NLS once we've recursed too many times in error processing, but that's
> >surely pretty ugly.  What would be a lot more user-friendly would be to
> >refuse the attempt to set client_encoding to something that can't handle
> >our error message encoding, but I don't know what a reasonable set of
> >restrictions would be.
>
> Maybe it's the time to convert all PO files to UTF-8. I'm in process to
> convert pt_BR ones.

I don't understand what do you think would be gained by doing that.  If
the message has chinese chars, a recode from UTF8 to Latin1 is as bad as
GB1232 to Latin1.

What needs to be done for this to work is to refuse trying to recode, as
Tom proposes above.  We would need to determine what recodes are "safe";
for example, (I think) valid encodings to Latin1 (iso 8859-1) are from
Latin9 (iso 8859-15 ?), Unicode and Win1252 and ASCII.  If the server
encoding or the encoding of the message files is a chinese encoding,
setting client_encoding to latin1 would raise an error.

The problem, I think, would be in determining what recodings are sane.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Re: NLS vs error processing, again

From
Peter Eisentraut
Date:
Tom Lane wrote:
> I'm far from an expert on this, but the gettext documentation
> indicates that it tries to translate the .po file contents into
> whatever encoding is implied by LC_CTYPE.

Correct.  That is just one more reason to have server encoding,
LC_COLLATE, and LC_CTYPE matching.  In practice, there is hardly a
reason to have LC_COLLATE and LC_CTYPE be different, so the problem
should not be that big.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Re: NLS vs error processing, again

From
Tatsuo Ishii
Date:
PiBKaWFuZ1dlaSA8ancucGdzcWxAc2R1ZXB0LmNvbT4gd3JpdGVzOg0KPiA+
ICAgICAgICAgTEFORz16aF9DTi5VVEYtOA0KPiA+IFsgc2V0IGNsaWVudF9l
bmNvZGluZyB0byBMQVRJTjEgYW5kIHByb3Zva2UgYW4gZXJyb3IgXQ0KPiAN
Cj4gT0ssIEkgY2FuIHJlcHJvZHVjZSB0aGUgY3Jhc2ggYWZ0ZXIgaW5pdGRi
J2luZyB3aXRoIHRoYXQgTEFORyBzZXR0aW5nDQo+IChpbiBhbiBubHMtZW5h
YmxlZCBidWlsZCkuICBUaGUgcG9zdG1hc3RlciBsb2cgZmlsbHMgd2l0aCBh
IHdob2xlIGxvdA0KPiBvZiBvY2N1cnJlbmNlcyBvZg0KPiANCj4g77+977+9
77+977+977+977+9OiAg77+977+977+977+977+977+977+977+977+977+9
77+977+977+977+977+977+977+977+977+977+977+9IFVURi04IO+/ve+/
ve+/ve+/ve+/ve+/vSAweDAwZTkNCj4g77+977+977+977+977+977+9OiAg
77+977+977+977+977+977+977+977+977+977+977+977+977+977+977+9
77+977+977+977+977+977+9IFVURi04IO+/ve+/ve+/ve+/ve+/ve+/vSAw
eDAwZTgNCj4g77+977+977+977+977+977+9OiAg77+977+977+977+977+9
77+977+977+977+977+977+977+977+977+977+977+977+977+977+977+9
77+9IFVURi04IO+/ve+/ve+/ve+/ve+/ve+/vSAweDAwZTgNCj4g77+977+9
77+977+977+977+9OiAg77+977+977+977+977+977+977+977+977+977+9
77+977+977+977+977+977+977+977+977+977+977+9IFVURi04IO+/ve+/
ve+/ve+/ve+/ve+/vSAweDAwZTgNCj4g77+977+977+977+977+977+977+9
77+977+977+977+977+977+977+977+977+977+977+977+977+977+977+9
77+977+977+977+977+977+977+977+977+977+977+9OiAgRVJST1JEQVRB
X1NUQUNLX1NJWkUgZXhjZWVkZWQNCj4gDQo+IFRyYWNpbmcgdGhyb3VnaCB0
aGUgZHVtcCBzaG93cyB0aGF0IHRoZSBlcnJvci1oYW5kbGluZyBjb2RlIGlz
DQo+IHJlY3Vyc2l2ZWx5IHByb2R1Y2luZyB0aGlzIHdhcm5pbmcgd2hpbGUg
dHJ5aW5nIHRvIHRyYW5zbGF0ZSB0aGUgd29yZA0KPiBXQVJOSU5HIHRvIExB
VElOMS4gIFRoZSB6aF9DTi5wbyBmaWxlIHNob3dzIHRoZSB0cmFuc2xhdGlv
biBhcw0KPiANCj4gIzogdXRpbHMvZXJyb3IvZWxvZy5jOjE5MDkNCj4gbXNn
aWQgIldBUk5JTkciDQo+IG1zZ3N0ciAi77+977+977+977+9Ig0KPiANCj4g
KHdoaWNoIGFwcGFyZW50bHkgaXMgR0IyMzEyPykNCg0KSXQgc2VlbXMuIHpo
X0NOLnBvIGhhcyB0aGUgbGluZToNCg0KIkNvbnRlbnQtVHlwZTogdGV4dC9w
bGFpbjsgY2hhcnNldD1HQjIzMTJcbiINCg0KV2hpY2ggbWVhbnMgYXQgbGVh
c3Qgc29tZW9uZSB3aG8gd3JvdGUgdGhlIGZpbGUgaW50ZW5kZWQgdG8gYmUg
aXQgYXMNCkdCMjMxMi4gSG93ZXZlciwgcGxlYXNlIG5vdGUgdGhhdCBHQjIz
MTIgaXMgYSBjaGFyYWN0ZXIgc2V0LCBub3QgYW4NCmVuY29kaW5nLiBUaGUg
cmVhbGl0eSBpcyB0aGF0IHRoZSBmaWxlIHNlZW1zIGVuY29kZWQgaW4gRVVD
LUNOLiBOb3RlDQp0aGF0IEkgaGF2ZSBjb25maXJtZWQgdGhpcyBieSBqdXN0
IGV4YW1pbmluZyB0aGUgYnl0ZXMgYWJvdmUNCijvv73vv73vv73vv70pIGFy
ZSBjb3JyZWN0IEVVQy1DTiBieXRlIHNlcXVlbmNlcy4gSXQgaXMgcG9zaWJi
bGUNCnRoYXQgdGhlIGZpbGUgaXMgbm90IHdyaXR0ZW4gaW4gRVVDLUNOLCBi
dXQgSSBndWVzcyBpdCdzIGhhcmRseQ0KcG9zc2libGUuDQoNCj4gYW5kIHdo
YXQncyBhY3R1YWxseSBnZXR0aW5nIHBhc3NlZCB0bw0KPiB1dGY4X3RvX2lz
bzg4NTlfMSgpIGlzDQo+IA0KPiAoZ2RiKSB4LzZvIHN0cg0KPiAweDhiODlk
ODogICAgICAgMDM1MCAgICAwMjU1ICAgIDAyNDYgICAgMDM0NSAgICAwMjIx
ICAgIDAyMTINCj4gDQo+IEkgaGF2ZSBubyBpZGVhIGlmIHRoaXMgaXMgYSBj
b3JyZWN0IFVURjggdHJhbnNsaXRlcmF0aW9uIG9mIHRoZSBHQjIzMTINCj4g
cGhyYXNlIC0tLSBjYW4gYW55b25lIGNvbmZpcm0/DQoNCkFzIGZhcyBhcyBs
b29raW5nIGludG8gdXRpbHMvbWIvVW5pY29kZS9ldWNfY25fdG9fdXRmOC5t
YXAsIHRoZQ0KdHJhbnNsYXRpb24gYWJvdmUgc2VlbXMgdG8gYmUgY29ycmVj
dC4gQlRXLCB3aG8gZG9lcyB0aGUgdHJhbnNsYXRpb24NCmZyb20gRVVDLUNO
IHRvIFVURi04PyBNYXliZSBnZXR0ZXh0KCk/DQotLQ0KVGF0c3VvIElzaGlp
DQpTUkEgT1NTLCBJbmMuIEphcGFuDQoNCj4gQnV0IGFueXdheSwgaWYgdGhp
cyBpcyBDaGluZXNlIHRoZW4gaXQncw0KPiBoYXJkbHkgc3VycHJpc2luZyB0
aGF0IHRoZXJlIHdvdWxkIGJlIG5vIExBVElOMSBlcXVpdmFsZW50LiAgQW5k
IHRoZW4NCj4gdHJ5aW5nIHRvIHJlcG9ydCB0aGUgcHJvYmxlbSBnZXRzIHVz
IGludG8gYSBuZXcgaW5zdGFuY2Ugb2YgdGhlIHNhbWUNCj4gcHJvYmxlbS4g
IEV2ZW4gdGhlIGNvZGUgdGhhdCdzIHN1cHBvc2VkIHRvIHN0b3AgZXJyb3Ig
cmVjdXJzaW9uIGRvZXNuJ3QNCj4gZ2V0IHVzIG91dCBvZiBpdC4NCj4gDQo+
IEl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlcmUgYmFzaWNhbGx5IGlzIG5vIGdy
YWNlZnVsIHNvbHV0aW9uIHRvIHRoaXMgc29ydA0KPiBvZiBtaXNtYXRjaC4g
IEl0IG1pZ2h0IGJlIHBvc3NpYmxlIHRvIGtsdWdlIHRoaW5ncyBzbyB0aGF0
IHdlIGRpc2FibGUNCj4gTkxTIG9uY2Ugd2UndmUgcmVjdXJzZWQgdG9vIG1h
bnkgdGltZXMgaW4gZXJyb3IgcHJvY2Vzc2luZywgYnV0IHRoYXQncw0KPiBz
dXJlbHkgcHJldHR5IHVnbHkuICBXaGF0IHdvdWxkIGJlIGEgbG90IG1vcmUg
dXNlci1mcmllbmRseSB3b3VsZCBiZSB0bw0KPiByZWZ1c2UgdGhlIGF0dGVt
cHQgdG8gc2V0IGNsaWVudF9lbmNvZGluZyB0byBzb21ldGhpbmcgdGhhdCBj
YW4ndCBoYW5kbGUNCj4gb3VyIGVycm9yIG1lc3NhZ2UgZW5jb2RpbmcsIGJ1
dCBJIGRvbid0IGtub3cgd2hhdCBhIHJlYXNvbmFibGUgc2V0IG9mDQo+IHJl
c3RyaWN0aW9ucyB3b3VsZCBiZS4NCj4gDQo+IENvbW1lbnRzPw0KPiANCj4g
CQkJcmVnYXJkcywgdG9tIGxhbmUNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLShlbmQgb2YgYnJvYWRjYXN0KS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KPiBUSVAgNTogZG9uJ3QgZm9yZ2V0IHRvIGluY3JlYXNl
IHlvdXIgZnJlZSBzcGFjZSBtYXAgc2V0dGluZ3MNCj4gDQo=

Re: NLS vs error processing, again

From
Bruce Momjian
Date:
Peter Eisentraut wrote:
> Tom Lane wrote:
> > I'm far from an expert on this, but the gettext documentation
> > indicates that it tries to translate the .po file contents into
> > whatever encoding is implied by LC_CTYPE.
>
> Correct.  That is just one more reason to have server encoding,
> LC_COLLATE, and LC_CTYPE matching.  In practice, there is hardly a
> reason to have LC_COLLATE and LC_CTYPE be different, so the problem
> should not be that big.

Is there any TODO here?

--
  Bruce Momjian   http://candle.pha.pa.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +