Re: [HACKERS] Conversion error
> Tatsuo Ishii writes: >> I saw this while restoring 9.6 database to 10.0 database. >> \connect: FATAL: conversion between UTF8 and MULE_INTERNAL is not supported >> Is this expected? I saw nothing releated to this in the release notes. > > Don't think that's ever been supported. Sorry, that was my misunderstanding. All versions of PostgreSQL allow to create MULE_INTERNAL database while executing restore, but after that it fails while loading rows into the mule internal database. So, if there's no table in the database, the restore succeeds. That's why I got wrong expressions. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Conversion error
Tatsuo Ishii writes: > I saw this while restoring 9.6 database to 10.0 database. > \connect: FATAL: conversion between UTF8 and MULE_INTERNAL is not supported > Is this expected? I saw nothing releated to this in the release notes. Don't think that's ever been supported. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Conversion error
> I saw this while restoring 9.6 database to 10.0 database. > > \connect: FATAL: conversion between UTF8 and MULE_INTERNAL is not supported > > Is this expected? I saw nothing releated to this in the release notes. This had been allowed in 9.6. So I think 10.0 silently drops the feature. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Conversion error
I saw this while restoring 9.6 database to 10.0 database. \connect: FATAL: conversion between UTF8 and MULE_INTERNAL is not supported Is this expected? I saw nothing releated to this in the release notes. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Conversion error of floating point numbers in pl/pgsql
On Tue, Nov 17, 2015 at 9:00 PM, Robert Haas wrote: > On Mon, Nov 16, 2015 at 9:49 AM, Tom Lane wrote: >> Kyotaro HORIGUCHI writes: >>> Hello. I found that 9.5 has an undocumented difference from 9.4 >>> in type cast in pl/pgsql and I think it might better be mentioned >>> as a change of behavior in release notes. >> >>> Whether do you think it is worth mentioning or not in release notes? >> >> This seems unnecessarily alarmist to me. Anybody who's in the habit >> of converting between float4 and float8 will already be used to this >> behavior, because it is what has always happened everywhere else in >> the system. > > Sure, but that doesn't mean nobody's functions will start behaving > differently. It seems worth mentioning as a backward compatibility > issue to me, because if something breaks, it may not be immediately > obvious why it has gotten broken. Agreed, but the note should be followed by another one warning against any expectations of floating point behavior below the precision threshold :-). merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Conversion error of floating point numbers in pl/pgsql
On Mon, Nov 16, 2015 at 9:49 AM, Tom Lane wrote: > Kyotaro HORIGUCHI writes: >> Hello. I found that 9.5 has an undocumented difference from 9.4 >> in type cast in pl/pgsql and I think it might better be mentioned >> as a change of behavior in release notes. > >> Whether do you think it is worth mentioning or not in release notes? > > This seems unnecessarily alarmist to me. Anybody who's in the habit > of converting between float4 and float8 will already be used to this > behavior, because it is what has always happened everywhere else in > the system. Sure, but that doesn't mean nobody's functions will start behaving differently. It seems worth mentioning as a backward compatibility issue to me, because if something breaks, it may not be immediately obvious why it has gotten broken. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Conversion error of floating point numbers in pl/pgsql
Hello, At Mon, 16 Nov 2015 09:49:54 -0500, Tom Lane wrote in <32508.1447685...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > Hello. I found that 9.5 has an undocumented difference from 9.4 > > in type cast in pl/pgsql and I think it might better be mentioned > > as a change of behavior in release notes. > > > Whether do you think it is worth mentioning or not in release notes? > > This seems unnecessarily alarmist to me. Anybody who's in the habit > of converting between float4 and float8 will already be used to this > behavior, because it is what has always happened everywhere else in > the system. I guess not a small number of users don't have an enough insight to antcipate such influence, but I'll agree to ommit this if such a kind of users are not in target of the release notes. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Conversion error of floating point numbers in pl/pgsql
Kyotaro HORIGUCHI writes: > Hello. I found that 9.5 has an undocumented difference from 9.4 > in type cast in pl/pgsql and I think it might better be mentioned > as a change of behavior in release notes. > Whether do you think it is worth mentioning or not in release notes? This seems unnecessarily alarmist to me. Anybody who's in the habit of converting between float4 and float8 will already be used to this behavior, because it is what has always happened everywhere else in the system. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Conversion error of floating point numbers in pl/pgsql
Hello. I found that 9.5 has an undocumented difference from 9.4 in type cast in pl/pgsql and I think it might better be mentioned as a change of behavior in release notes. Whether do you think it is worth mentioning or not in release notes? = 9.4 and 9.5 has difference in casting between floating point numbers. CREATE OR REPLACE FUNCTION hoge () RETURNS text AS $$ DECLARE vr real; vf8 float8; BEGIN vr := 0.1; vf8 = vr; RETURN 'hoge = '|| vf8 ; END; $$ LANGUAGE plpgsql; 9.5=# select hoge(); hoge -- hoge = 0.10001490116 9.4=# select hoge(); hoge hoge = 0.1 This is stemming from the difference between '0.1'::real::float8 and '0.1'::real::text::float8, made in exec_cast_value(). =# select '0.1'::real::float8, '0.1'::real::text::float8; float8 | float8 ---+ 0.10001490116 |0.1 This example itself looks somewhat artifitial but it would be rather common to load real values in a table into float8 variables in a function for further calculations. This is a side effect of the commit 1345cc67bbb014209714af32b5681b1e11eaf964 and the relase notes has the following discription corresponds to this commit in the Migration section, with no mention of this. > Use assignment cast behavior for data type conversions in > PL/pgSQL assignments, rather than converting to and from text > (Tom Lane) > > This change causes conversions of Booleans to strings to produce > true or false, not t or f. Other type conversions may succeed in > more cases than before; for example, assigning a numeric value > 3.9 to an integer variable will now assign 4 rather than > failing. If no assignment-grade cast is defined for the > particular source and destination types, PL/pgSQL will fall back > to its old I/O conversion behavior. Whether do you think it is worth mentioning or not? Though the attached patch adds a description for that, it should be rewritten even if this is worth mentioning. + This change also may bring different results of type casts + between floating point numbers having different conversion + errors. regards, -- Kyotaro Horiguchi NTT Open Source Software Center diff --git a/doc/src/sgml/release-9.5.sgml b/doc/src/sgml/release-9.5.sgml index 64057c3..5c86222 100644 --- a/doc/src/sgml/release-9.5.sgml +++ b/doc/src/sgml/release-9.5.sgml @@ -108,7 +108,9 @@ an integer variable will now assign 4 rather than failing. If no assignment-grade cast is defined for the particular source and destination types, PL/pgSQL will fall back to its old - I/O conversion behavior. + I/O conversion behavior. This change also may bring different results of + type casts between floating point numbers having different conversion + errors. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
