Describe the bug
The Oracle-to-PostgreSQL converter maps plain Oracle FLOAT to PostgreSQL DOUBLE PRECISION.
Oracle FLOAT is a subtype of NUMBER. It is distinct from BINARY_FLOAT. Mapping it to DOUBLE PRECISION changes decimal NUMBER semantics to approximate IEEE 754 binary arithmetic.
To Reproduce
Example from https://techcommunity.microsoft.com/blog/adforpostgresql/oracle-to-postgresql-in-vs-code-assessment-conversion-and-validation/4544728:
function from_mills_to_secs(value integer) return float is
real_value float := 0;
begin
real_value := value/1000;
return real_value;
exception
when zero_divide then
real_value := 0;
return real_value;
end from_mills_to_secs;
was converted to:
CREATE OR REPLACE FUNCTION soe.orderentry$from_mills_to_secs(value integer)
RETURNS double precision
LANGUAGE plpgsql
IMMUTABLE
AS $$
DECLARE
real_value double precision := 0;
BEGIN
real_value := value::double precision / 1000.0;
RETURN real_value;
EXCEPTION
WHEN division_by_zero THEN
real_value := 0;
RETURN real_value;
END;
$$;
Expected behavior
- Treat Oracle
FLOAT and FLOAT(p) as NUMBER subtypes.
- Map them to unconstrained PostgreSQL
numeric by default.
- Keep
BINARY_FLOAT to real and BINARY_DOUBLE to double precision.
Note: numeric(38) is not a safe generic default: in PostgreSQL it means
numeric(38,0) and therefore imposes scale zero. Oracle FLOAT(p) specifies
binary precision and no fixed decimal scale, so unconstrained numeric is the
conservative general mapping.
Evidence
The type mappings in instructions.yaml include:
- NUMBER(p,s) -> NUMERIC(p,s) preserving exact precision
- NUMBER with no precision -> NUMERIC (unconstrained)
- BINARY_FLOAT -> REAL
- BINARY_DOUBLE -> DOUBLE PRECISION
There is no rule for plain Oracle FLOAT or FLOAT(p). The packaged feature
mapping documentation and static verification design also list
BINARY_FLOAT and BINARY_DOUBLE, but not FLOAT.
The extractor preserved the source type as float; it did not classify it as
BINARY_FLOAT or BINARY_DOUBLE. Nevertheless, the conversion.log reports:
Mapped Oracle FLOAT to PostgreSQL DOUBLE PRECISION per required mapping.
No such required mapping is present in the instructions.
Describe the bug
The Oracle-to-PostgreSQL converter maps plain Oracle FLOAT to PostgreSQL DOUBLE PRECISION.
Oracle FLOAT is a subtype of NUMBER. It is distinct from BINARY_FLOAT. Mapping it to DOUBLE PRECISION changes decimal NUMBER semantics to approximate IEEE 754 binary arithmetic.
To Reproduce
Example from https://techcommunity.microsoft.com/blog/adforpostgresql/oracle-to-postgresql-in-vs-code-assessment-conversion-and-validation/4544728:
was converted to:
Expected behavior
FLOATandFLOAT(p)asNUMBERsubtypes.numericby default.BINARY_FLOATtorealandBINARY_DOUBLEtodouble precision.Note:
numeric(38)is not a safe generic default: in PostgreSQL it meansnumeric(38,0)and therefore imposes scale zero. OracleFLOAT(p)specifiesbinary precision and no fixed decimal scale, so unconstrained
numericis theconservative general mapping.
Evidence
The type mappings in
instructions.yamlinclude:There is no rule for plain Oracle
FLOATorFLOAT(p). The packaged featuremapping documentation and static verification design also list
BINARY_FLOATandBINARY_DOUBLE, but notFLOAT.The extractor preserved the source type as
float; it did not classify it asBINARY_FLOATorBINARY_DOUBLE. Nevertheless, theconversion.logreports:No such required mapping is present in the instructions.