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