| From: | neha khatri <nehakhatri5(at)gmail(dot)com> |
|---|---|
| To: | pgsql-novice(at)postgresql(dot)org |
| Subject: | Regression test : pg_conversion validation |
| Date: | 2017-02-13 04:59:34 |
| Message-ID: | CAFO0U+8tGef__nVrhKSQo5sOae-4s6uc84ChoVwLPH=fdffF4A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-novice |
In PostgreSQL9.6, the test opr_sanity from server regression suite has
added following validations for the System Catalog pg_conversion.
SELECT p1.oid, p1.conname
FROM pg_conversion as p1
WHERE condefault AND
convert('ABC'::bytea, pg_encoding_to_char(conforencoding),
pg_encoding_to_char(contoencoding)) != 'ABC';
It looks like this validation might not reflect the correct behaviour for a
well defined conproc for certain encodings.
e.g. Consider LATIN1 as src_encoding and EBCDIC as dst_encoding in the
above query. Now the convert() result for this should be:
select convert('ABC'::bytea,'LATIN1','EBCDIC');
convert
----------
\xc1c2c3
The resultant hex value above(which is the actual EBCDIC code for 'ABC') is
not same as ASCII hex value for 'ABC'. Hence the validation query from
opr_sanity would show this conproc in the output indicating that the
conproc is not well defined. This does not seem correct.
Please let me know if this understanding is correct. If it is, then the
validation test should indicate that the specific conversion is a valid
conversion.
Regards,
Neha
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-02-13 07:27:11 | Re: Regression test : pg_conversion validation |
| Previous Message | Rounak Jain | 2017-02-12 15:26:46 | are separate join tables necessary/important like in Filemaker |