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" ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
