Letting SPI deduce parameter types doesn't work as well as the old code

[GoogleCodeExporter]

What steps will reproduce the problem?

1. we have an operator !<@ which compares an int to and array of ints 
2. prepare select * from foo where id = ARRAY[$1] fails due to defaulting to 
text[]  
3.

if you remove the new SPI code this works fine

Original issue reported on code.google.com by davecra...@gmail.com on 17 Apr 2013 at 10:21

[GoogleCodeExporter]

It's not clear to me why !<@ operator affects = operator type deduction.  Can 
you show me self-contained repro?

Original comment by umi.tan...@gmail.com on 15 May 2013 at 6:19

[GoogleCodeExporter]

I believe this is a repro.

create or replace function myopr(a int, b int[]) returns bool as $$
  for(var i = 0; i < b.length; i++) {
    if (a < b[i]) return false;
  }
  return true;
$$ language plv8 immutable strict;
create operator !<@ (
  procedure = myopr,
  leftarg = int,
  rightarg = int[]
);

create table tbl (id int);
do language plv8 $$
var plan = plv8.prepare("select * from tbl where id = array[$1]");
plan.execute(1);
$$;

Original comment by umi.tan...@gmail.com on 15 May 2013 at 6:29

[GoogleCodeExporter]

It seems this doesn't work for the same reason as the following doesn't work.

select 1 !<@ array['1'];
ERROR:  operator does not exist: integer !<@ text[]
LINE 1: select 1 !<@ array['1'];
                 ^

because the element of array expression is unknown type and operator expression 
tries to find the appropriate type, but because array type is not yet 
determined, element type is determined first, and because element is a 
"unknown" type, it is coerced to text.  So the entire array expression is 
recognized as text[].  I don't think there is a short solution to that because 
we don't have "unknown[]" type so we end up finding a common type which is here 
text for the element.  

Original comment by umi.tan...@gmail.com on 15 May 2013 at 7:14

[GoogleCodeExporter]

> I don't think there is a short solution to that because we don't have 
"unknown[]" type so we end up finding a common type which is here text for the 
element. 

Let me rephrase it.  Because array expression type deduction is done by element 
basis, and it is the operator that knows possible expression types, and those 
two knowledge is not interacting each other currently, it is not easy to do it. 
 Anyway it is a postgres issue, I guess.

Original comment by umi.tan...@gmail.com on 15 May 2013 at 7:18