PL/php

So, long time no updates, but we are pretty close to complete the implementation. My original idea was to model it after PL/pgSQL, as Alvaro suggested earlier, but I found out that building a row type for the result is not necessary, since OUT arguments are represented as a RECORD return type internally, and we already have support for returning records. Thus, adding OUT arguments appeared to be quite straightforward. For a single OUT, it's sufficient to add a 'return $argument_name' statement at the very end of the function during the compilation stage. For multiple OUTs, the approach is the same, but instead of returning a scalar value, an array of references to OUT arguments is created and returned. For instance, here's the function declaration as supplied by a user, and the resulting code just before the compilation:

CREATE OR REPLACE FUNCTION plphp_multiple_out(OUT integer, OUT name text, INOUT date) AS 
$$
  $args[0] = 1; $args[1] = 'jdoe';
$$ LANGUAGE plphp;
SELECT * FROM plphp_multiple_out(current_date); 

function plphp_proc_24616($args, $argc){ $name = &$args[1];  $_plphp_ret_plphp_proc_24616 = array(&$args[0],&$args[1],&$args[2]);
      $args[0] = 1; $args[1] = 'jdoe';
    ; return $_plphp_ret_plphp_proc_24616;}

(A minor improvement I've just discovered is to return the array(...) statement itself, without creating a name for it).

Initially I have decided to skip the OUT arguments altogether when building an argument list for the function, but this appeared to be incompatible with unnamed OUT arguments (we need to refer to them somehow), so I've used the idea from PL/pgSQL to initialize them with NULL values initially.

I also had to modify the code that builds a postgres tuple from the PHP array to support the normal non-assosiative arrays (i.e. array(1,2,3) instead of array('one'=>1, 'two'=>2, 'three'=>3), so it's not necessary to specify argument names when returning multiple values a function.

What's left is the support for TABLE arguments (aka SRF OUT arguments) and test cases. I'd think that it needs an extra day of work.

So, I've got the SRF functions with OUT arguments working, but came over one problem when dealing when TABLE arguments (which are basically a syntax sugar over the SRF with OUTs). The pl/pgSQL implementation of TABLE arguments allows for doing RETURN NEXT w/o specifying the row to return (in fact, it explicitly forbids putting the row there) and automatically fills the return value with a row constructed from the TABLE arguments. I'd like to do this in PHP as well, but since we don't have such intimate relationship with a PHP parser as pl/pgSQL enjoys, we use a separate function called return_next. This function, naturally, doesn't have access to the variables passed into the original function, but we need to get their values somehow to construct the resulting tuple. The approach I'm currently exploring is to save the symbol table of the pl/PHP function into a global variable right before passing control to the PHP parser, and accessing this table from return_next.

Alexey Klyukin wrote:

This function, naturally, doesn't have access to the variables passed into the original function, but we need to get their values somehow to construct the resulting tuple. The approach I'm currently exploring is to save the symbol table of the pl/PHP function into a global variable right before passing control to the PHP parser, and accessing this table from return_next.

This idea was not working, because we never passed the symbol table prepared just before the actual function call to the PHP function itself. Instead, that symbol table represented an outer block for the function, and we passed the argc and argv parameters via the function signature (by assigning values to argc and argv in our outer block (C function) and then calling plphp_proc_$oid(argc, argv)). By examining the PHP sources I've discovered that we can pass our prepared symbol table directly to the function via the last parameter of call_user_function_ex. I've checked this and it appears to be working. So the last problem seems to be solved, but I need a bit more testing (and some refactoring) to finish with this.