Обсуждение: casting zero-length strings

Chris KL recently pointed out to me that we currently don't raise an
error when attempting to cast a zero-length string to a float:

nconway=# select ''::float8;float8
--------     0
(1 row)

nconway=# select ''::float4;float4
--------     0
(1 row)

Similarly for oid:

nconway=# select ''::oid;oid
-----  0
(1 row)

Whereas int and numeric reject zero-length strings:

nconway=# select ''::int;
ERROR:  invalid input syntax for integer: ""
nconway=# select ''::numeric;
ERROR:  invalid input syntax for type numeric: ""

So, should we fix oid and float?

I'm leaning toward "yes", for the sake of consistency and
sanity. However, we were bitten by backward-compatibility concerns
when we made a similar change to the "int" input rules during the 7.3
cycle, so I'm open to other suggestions.

-Neil

Neil Conway <neilc@samurai.com> writes:
> Chris KL recently pointed out to me that we currently don't raise an
> error when attempting to cast a zero-length string to a float:
> Whereas int and numeric reject zero-length strings:

> So, should we fix oid and float?

Yes, surely, unless someone wants to argue for reverting that change
to pg_atoi.  I can't see a reason for having them act inconsistently.

While we are at it we should make sure these functions are all on the
same page about allowing leading/trailing whitespace.  I seem to recall
that the spec says somewhere that both should be allowed ... but right
now I do not think we allow trailing whitespace.
        regards, tom lane

> Yes, surely, unless someone wants to argue for reverting that change
> to pg_atoi.  I can't see a reason for having them act inconsistently.
> 
> While we are at it we should make sure these functions are all on the
> same page about allowing leading/trailing whitespace.  I seem to recall
> that the spec says somewhere that both should be allowed ... but right
> now I do not think we allow trailing whitespace.

Either way, we should make them a WARNING for 7.5, then error in 7.6. 
The pg_atoi change was a bit disastrous because of instant error I thought.

Chris

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> Either way, we should make them a WARNING for 7.5, then error in
> 7.6.

Ok, I'll make this change soon.

If we end up marking more 7.5 changes using this mechanism
(i.e. deprecate for 7.5, disallow for 7.6), we could use an #ifdef
symbol to mark all the changes that need to be made permanent for 7.6:

#ifdef 7_5_DEPRECATED_FUNCTIONALITY
...
#endif

Cheers,

Neil