Package org.postgresql.pljava.example.annotation

Class ComplexScalar

java.lang.Object
org.postgresql.pljava.example.annotation.ComplexScalar
All Implemented Interfaces:
SQLData
@SQLAction(requires={"complex assertHasValues","complex relationals"},
           install={"CREATE OPERATOR CLASS javatest.complex_ops  DEFAULT FOR TYPE javatest.complex USING btree AS  OPERATOR 1 javatest.<  ,  OPERATOR 2 javatest.<= ,  OPERATOR 3 javatest.=  ,  OPERATOR 4 javatest.>= ,  OPERATOR 5 javatest.>  ,  FUNCTION 1 javatest.cmpMagnitude(javatest.complex,javatest.complex)","SELECT javatest.assertHasValues( CAST(\'(1,2)\' AS javatest.complex), 1, 2)","SELECT javatest.assertHasValues( 2.0 + CAST(\'(1,2)\' AS javatest.complex) + 3.0, 6, 2)","SELECT CASE WHEN  \'(1,2)\'::javatest.complex < \'(2,2)\'::javatest.complex AND  \'(2,2)\'::javatest.complex > \'(1,2)\'::javatest.complex AND  \'(1,2)\'::javatest.complex <= \'(2,2)\'::javatest.complex THEN javatest.logmessage(\'INFO\', \'ComplexScalar operators ok\') ELSE javatest.logmessage(\'WARNING\', \'ComplexScalar operators ng\') END"},
           remove="DROP OPERATOR FAMILY javatest.complex_ops USING btree")
@BaseUDT(schema="javatest",
         name="complex",
         internalLength=16,
         alignment=DOUBLE)
public class ComplexScalar
extends Object
implements SQLData
Complex (re and im parts are doubles) implemented in Java as a scalar UDT.

The SQLAction here demonstrates a requires tag ("complex relationals"} that has multiple providers, something not allowed prior to PL/Java 1.6.1. It is more succinct to require one tag and have each of the relational operators 'provide' it than to have to define and require several different tags to accomplish the same thing.

The operator class created here is not actively used for anything (the examples will not break if it is removed), but the minMagnitude example aggregate does specify a sortOperator, which PostgreSQL will not exploit in query optimization without finding it as a member of a btree operator class.

Note that CREATE OPERATOR CLASS implicitly creates an operator family as well (unless one is explicitly specified), so the correct remove action to clean everything up is DROP OPERATOR FAMILY (which takes care of dropping the class).