Tom Lane writes:
> 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
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Considering that the data type float(x) isn't documented anywhere, I'm not
> worried.
Good point ... I'll fix that while I'm at it ...
regards, tom lane
---(end of broadcast)---
"Shridhar Daithankar" <[EMAIL PROTECTED]> writes:
> 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
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. Th
Tom Lane wrote:
> 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 proble
