Creating a PostgreSQL procedural language - Part 3 - Executing User Code

February 25, 2020

A PostgreSQL procedural language handler needs to look up the body of the user defined function or stored procedure for the code to execute.  Remember that the C function executed to handle PL/Julia user defined functions and stored procedures is defined in the SQL file. Thus the pljulia_call_handler() function needs to be updated to retrieve the body of the respective function or procedure.

The following code examples are abbreviated and broken up a bit to hopefully make it easier to follow the general flow of the code.  The complete changes are on GitHub.

The bulk of the new code is around retrieving the body of the user defined function or stored procedure that is being called.  The identifier of the function or procedure is passed to the procedural language handler as fcinfo->flinfo->fn_oid, so it is just a matter of searching the PostgreSQL system cache with that identifier and retrieving the body of the function with the following code.

 

    HeapTuple procedure_tuple;
    Datum procedure_source_datum;
    const char *procedure_code;
    bool isnull;

    procedure_tuple = SearchSysCache(PROCOID,
            ObjectIdGetDatum(fcinfo->flinfo->fn_oid), 0, 0, 0);

    procedure_source_datum = SysCacheGetAttr(PROCOID, procedure_tuple,
            Anum_pg_proc_prosrc, &isnull);

    procedure_code = DatumGetCString(DirectFunctionCall1(textout,
            procedure_source_datum));

Now we have a copy of the Julia code stored in a string variable called procedure_code.  It can be executed by passing it to Julia with the jl_eval_string() API call, which will then return the results from the code into a special variable ret.  There will be more on this special variable in a later blog.

    jl_value_t *ret;
    ret = jl_eval_string(procedure_code);

In keeping the example short, I omitted much of the error handling in the previous snippets but they do exist.  Now that we are able to execute arbitrary Julia code, it is important to note how to detect whenever there is any issue with the code.  Julia’s C API provides a function to check for exceptions and we will capture all issues into PostgreSQL log.

    if (jl_exception_occurred())
            elog(ERROR, "%s", jl_typeof_str(jl_exception_occurred()));

In order to keep the changes to the code small, we will continue to only check if the executed code from the user defined function or stored procedure is a Julia float64 data type and capture the results of the executed Julia code into the PostgreSQL log.

    if (jl_typeis(ret, jl_float64_type))
    {
        double ret_unboxed = jl_unbox_float64(ret);
        elog(DEBUG1, "ret: %e", ret_unboxed);
    }

These changes now allow us to write a PL/Julia user defined function to calculate the square root of 2, instead of hard coding it into the procedural language handler.

CREATE OR REPLACE FUNCTION test_julia()
RETURNS VOID
AS $$
    sqrt(2.0);
$$ LANGUAGE pljulia;

There is still more work to be done in order to return the results back to the SQL statement, but for now we can write functions in Julia that return floating point numbers.

Share this

Relevant Blogs

Random Data

This post continues from my report on Random Numbers. I have begun working on a random data generator so I want to run some tests to see whether different random...
December 03, 2020

More Blogs

Full-text search since PostgreSQL 8.3

Welcome to the third – and last – part of this blog series, exploring how the PostgreSQL performance evolved over the years. The first part looked at OLTP workloads, represented...
November 05, 2020

Números aleatorios

He estado trabajando gradualmente en el desarrollo desde cero de herramientas para probar el rendimiento de los sistemas de bases de datos de código abierto. Uno de los componentes de...
November 04, 2020