Re: [HACKERS] Our FLOAT(p) precision does not conform to spec

On 16 Jun 2003 at 18:15, Tom Lane wrote:
> This is a straightforward change and would not break pg_dump files,
> since fortunately pg_dump always references the underlying types and
> never refers to anything as FLOAT(p). But I wonder whether it is
> likely to break many existing applications. There is a hazard of some
> existing app asking for (what it thinks is) float8 and getting float4
> instead.

Especially apps. which rely on number(3) not to accept anything greate than +/-
999.

I hate the syntax of putting decimal digits as range checkers in SQL field. But
oracle does that and consequently lot of oracle apps rely on it. I won't be
surprised if float(p) notion brings same assurance to such app developers.

I think this would become and FAQ after changes are implemented. Who reads
release notes anyway?..:-)

> Is it worth trying to provide some sort of backwards-compatibility mode?
> We could imagine adding a GUC variable to select binary or decimal
> precision, but I really don't want to. It would increase the amount of
> work needed by more than an order of magnitude, and this problem doesn't
> seem worth it. I'd rather just list this under Incompatibilities in the
> 7.4 release notes.

Is it possible to have float-2(p) and float-10(p)? Would it be adding code
sections instead of replacing it?

That would be cleaner than GUC variable. Everything defaults to float-10(p) for
backward compatibility for a period of a release and in 7.5, it gets switched
to float-2(p). In the meantime, the behaviour remains available who cares to
read the docs and notes.

Just a thought..

Bye
Shridhar

--
Genderplex, n.: The predicament of a person in a restaurant who is unable to
determine his or her designated restroom (e.g., turtles and tortoises). --
Rich Hall, "Sniglets"