Re: ERROR: invalid input syntax for integer: "" - Mailing list pgsql-general
From | Ben Madin |
---|---|
Subject | Re: ERROR: invalid input syntax for integer: "" |
Date | |
Msg-id | E84B50CE-B900-412D-8C01-57F058122EE6@ausvet.com.au Whole thread Raw |
In response to | Re: ERROR: invalid input syntax for integer: "" (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: ERROR: invalid input syntax for integer: ""
Re: ERROR: invalid input syntax for integer: "" |
List | pgsql-general |
Thanks Tom, On 2013-02-06, at 13:42 , Tom Lane <tgl@sss.pgh.pa.us> wrote: > The only part of this query that looks like it could possibly produce > that error is the res8.resultvalue-to-int cast: >> LEFT JOIN results res8 ON res8.reportid =3D rep.id AND = res8.resulttypeid =3D 108 AND res8.del =3D false >> LEFT JOIN resultlookup rlu8 ON rlu8.resulttypesid =3D 108 AND rlu8.id = =3D res8.resultvalue::int > = ^^^^^^^^^^^^^^^^^^^^^ > Presumably, there are some empty strings in results.resultvalue, and = if > the query happens to try to compare one of them to rlu8.id, kaboom. Yes - this would be the case if it tried to match it against the = resultvalue only - some of the values in the table are NULL, but not for = this resulttypeid. So my understanding, working left to right was that the res.8 table rows = should be limited to those rows which have a resulttypeid =3D 108. These = all have numeric values, vis : select distinct resultvalue from results where resulttypeid =3D 108 = order by resultvalue; = =20 resultvalue=20 ------------- 932.0 933.0 934.0 935.0 936.0 937.0 938.0 939.0 940.0 3224.0 (10 rows) and it should then be only these rows that are joined to the = resultlookup table=85 but it seems that the rlu8.id =3D res8.resultvalue = is being done first. Can I prevent that? Using a subquery, or a some other approach. > The way that the error comes and goes depending on = seemingly-irrelevant > changes isn't too surprising. Probably what's happening is that the > query plan changes around so that that test occurs earlier or later > relative to other join clauses. That might just be it - the query explain is different for the same = query on each machine.=20 Just to confuse the issue, if I take the resultlookup table out = completely, I still get the same error. So maybe it isn't that join at = all that is raising the error. If I take the results table out=85 it works(the commented code below = being the change.)=20 SELECT rep.id, --res.reportid,=20 = round(st_distance_sphere('0101000020BB1000008716D9CEF7A36240643BDF4F8DA741= C0', post.the_point)/1000) as dist=20 FROM reports rep=20 LEFT JOIN users u ON rep.link =3D u.id=20 LEFT JOIN postcodes post ON u.postcode::integer =3D post.postcode =20 LEFT JOIN species spe ON rep.species::text like spe.speccode::text AND = spe.synonym =3D 0 =20 --LEFT JOIN results res ON rep.id =3D res.reportid AND res.resulttypeid = =3D 108 AND res.del is false WHERE rep.del IS false AND rep.projectid =3D 51 AND round(st_distance_sphere( = '0101000020BB1000008716D9CEF7A36240643BDF4F8DA741C0', = post.the_point)/1000) < 150 AND spe.id =3D 9465; I'm really not sure what to do here. cheers Ben --=20 Ben Madin m : +61 448 887 220 e : ben@ausvet.com.au
pgsql-general by date: