[rfc] new CREATE FUNCTION (and more) - Mailing list pgsql-hackers

Situation: 7.1 has a new backend interface for loadable modules. (but it supports old 7.0 interface too)

Now the problem: How do you tell the backend with what interface to use for particular function?  At the moment 7.1-cvs
uses'newC' instead of 'C' in the LANGUAGE part.
 

But this not good:

1) the 'newC' will be quite silly after couple of years, when it  will be the standard.

2) there is another change in the horizon, which would be the  automatic detection of function parameters, or rather
the shared object should provide info about it.
 

3) It has nothing to do with 'C'.  The loadable modules can be  programmed in any language, as long it supports C
calling conventions.
 

4) And IMHO "LANGUAGE 'C'" is a hack, LANGUAGE construct should be  used only for actual definitions.  Now should we
extendone hack  with another hack?
 


Requirement: 7.1 should understand the 7.0 syntax, 7.2 should understand 7.1 and 7.0 syntax.  That means the
dump/restoreshould work between versions.  Whether 7.2 has the 'oldC' handler is another matter, but it should not load
itwith wrong defaults.
 

I propose new command:
 CREATE FUNCTION name( [ftype [, ...] ] ) RETURNS rtypeFROM [ LIBRARY ] obj_file AS link_sym[ WITH [ TYPE = ( 0 | 1 |
...) ]       [[,] ATTRIBUTE = ( attr [, ...] ) ] ]
 
   This mostly like the current "CREATE FUNCTION .. LANGUAGE 'C'".   Main difference is that the TYPE=0 means the old
'C'interface   and TYPE=1 means 'newC' interface.  Default is 1.  (As said,   7.1 supports the old LANGUAGE 'C'
variant,so I think it is   not needed the default to be 0.)
 

 CREATE FUNCTION ... AS defn ... LANGUAGE 'C' ..
   means 7.0 oldC/Informix interface.  No new languages will   come in this way.  (I mean those where the defn is
actually  objname, symbol pair.)      This only is for compatibility.  The ".. LANGUAGE .." should   be only used for
theactual definitions.
 

Alternative:
 newC will be created as:
   CREATE FUNCTION .. LANGUAGE 'C' WITH (pg_params)
 default is old_params, 7.1 pg_dump dumps newC with "(pg_params)". But as I said this is a hack.


Now some future ideas.  I really think that something like that
should come into PostgreSQL eventually.

 LOAD MODULE name FROM [LIBRARY] foomodule.so
   The lib has a struct (e.g.) pg_module_<name>_info which defines   init/remove functions, functions, operators and
types. PostgreSQL   registers module somehow, and when the module gets DROPped then   PostgreSQL calls its remove
funtionsand removes all stuff it has   itself registered.
 
 LOAD FUNCTION name FROM [LIBRARY] foo.so
   This means that in the object file there is defined struct   (e.g.) pg_function_<name>_info. (Probably by help of
macros).
{ I am not sure if the following is needed, better they go through  the LOAD MODULE? }
 LOAD TYPE name FROM [LIBRARY] foo.so
   Module has struct (e.g.) pg_type_<name>_info.
 LOAD OPERATOR name FROM [LIBRARY] foo.so AS obj_name
   Module has struct (e.g.) pg_operator_<obj_name>_info

Random notes:

* why struct not some init funtion? ->* it will be easier to function/module programmer.* avoids duplicate code* makes
possibledifferent interfaces.* main backend can detect incompatible interface
 

* I am not knowledgeable in dump/restore problems.  Someone who is should comment on this what features are else
needed.

* The *.so finding should accept some search paths (LD_LIBRARY_PATH?) (Does it now?)

* In future maybe some currently 'core' parts can be separated into 'core modules' e.g. all geometric stuff.  So they
canbe loaded only as needed.
 

* There was a previous discussion on modules:
 Mark Hollomon's idea:
http://www.postgresql.org/mhonarc/pgsql-hackers/1999-06/msg00959.html
 Jan Wieck objections:
http://www.postgresql.org/mhonarc/pgsql-hackers/1999-06/msg00983.html
 IMHO the objections are not very strong but sure the modules interface needs lot of work.



-- 
marko