Thread: "It'd be better if there were not an implicit cast from int8 to text..."
Hm, I suppose this "kluge" in gram.y for "substr_list" isn't necessary any more? Don't really see a downside to leaving it, just thought I would mention it since I noticed the comment is outdated. | a_expr substr_for { /* * Since there are no cases where this syntax allows * a textual FORvalue, we forcibly cast the argument * to int4. This is a kluge to avoid surprising results * when theargument is, say, int8. It'd be better if * there were not an implicit cast from int8 to text ... */ A_Const *n = makeNode(A_Const); n->val.type = T_Integer; n->val.val.ival = 1; $$ = list_make3($1,(Node *) n, makeTypeCast($2, SystemTypeName("int4"))); } -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Gregory Stark <stark@enterprisedb.com> writes: > Hm, I suppose this "kluge" in gram.y for "substr_list" isn't necessary any > more? It's still necessary, because if you write select substring('1234' for '3'); you should get "123", but what you will get without the cast is "3" because the preferred match will be to substring(text,text). Also, the original example was from someone who had tried to use a bigint column for the second parameter. That case would start to draw ERROR: function pg_catalog.substring(unknown, bigint) does not exist which doesn't seem helpful, when we know perfectly well that the only functions this syntax should match take int4. Probably the comment should be fixed. regards, tom lane