Thread: 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