[HACKERS] It'd be better if there were not an implicit cast from int8 to text...

2007-08-18 Thread Gregory Stark 

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 FOR value, we forcibly cast the argument
   * to int4. This is a kluge to avoid surprising results
   * when the argument 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

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] It'd be better if there were not an implicit cast from int8 to text...

2007-08-18 Thread Tom Lane 
Gregory Stark [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match