Thread
-
rule system, perl and other good stuff
Brett McCormick <brett@work.chicken.org> — 1998-02-11T06:41:17Z
don't want to bring up a touchy subject, BUT... does the rule system actually work, and if not, what are our plans? It would extend the functionality of postgresql quite a bit and make it much more attractive.. also I'm working on a modified version of pg with perl language support. that's right, perl. so far I've got it to the point where you can create perl functions (using anon sub refs) and access your arguments and perform operations (from pg_operator) on them. I'll get the patches together soon, once I add operator overloading :) one more thing -- what about making the listen/notify interface synchronous? what must be done? and... and... select foo[5:] for elements 5 and onward in array foo..
-
Re: [HACKERS] rule system, perl and other good stuff
Brett McCormick <brett@work.chicken.org> — 1998-02-11T07:26:21Z
DOH -- that's another question I meant to ask, as I noticed some things in the new (6.3) code about it.. no, it isn't, it is hacked in just like fmgr_dynamic is.. what do I need to know about the create language interface.. any docs? On Wed, 11 February 1998, at 14:26:23, Vadim B. Mikheev wrote: > One question: is your perl language support compatible with > new dynamic language interface (CREATE LANGUAGE etc) ? > > Vadim
-
Re: [HACKERS] rule system, perl and other good stuff
Vadim B. Mikheev <vadim@sable.krasnoyarsk.su> — 1998-02-11T07:26:23Z
Brett McCormick wrote: > > don't want to bring up a touchy subject, BUT... does the rule system > actually work, and if not, what are our plans? It would extend the > functionality of postgresql quite a bit and make it much more > attractive.. also I'm working on a modified version of pg with perl > language support. that's right, perl. so far I've got it to the > point where you can create perl functions (using anon sub refs) and > access your arguments and perform operations (from pg_operator) on > them. I'll get the patches together soon, once I add operator > overloading :) One question: is your perl language support compatible with new dynamic language interface (CREATE LANGUAGE etc) ? Vadim
-
Re: [HACKERS] rule system, perl and other good stuff
Brett McCormick <brett@work.chicken.org> — 1998-02-11T07:29:39Z
I don't see CREATE LANGUAGE in the grammar file... are you asking if it is strictly compatible or if it uses the dynamic language interface? there's no reason it shouldn't be compatible.. On Wed, 11 February 1998, at 14:26:23, Vadim B. Mikheev wrote: > One question: is your perl language support compatible with > new dynamic language interface (CREATE LANGUAGE etc) ? > > Vadim
-
Re: [HACKERS] rule system, perl and other good stuff
Brett McCormick <brett@work.chicken.org> — 1998-02-11T07:40:41Z
okay... yes it can co-exist with CREATE LANGUAGE as long as it is coded into the server like fmgr_dynamic is. it will not function as a CREATE LANGUAGE function. this is because all that this functionality appears to do is associate a single function with a language. but it does not pass the prosrc attribute (or probin for that matter) to the function, so no matter what you say for as 'insert code here', it never gets to the function, so the function has no idea what to do! I must be missing something. On Tue, 10 February 1998, at 23:29:39, Brett McCormick wrote: > I don't see CREATE LANGUAGE in the grammar file... are you asking if > it is strictly compatible or if it uses the dynamic language interface? > there's no reason it shouldn't be compatible.. > > On Wed, 11 February 1998, at 14:26:23, Vadim B. Mikheev wrote: > > > One question: is your perl language support compatible with > > new dynamic language interface (CREATE LANGUAGE etc) ? > > > > Vadim
-
Re: [HACKERS] rule system, perl and other good stuff
Vadim B. Mikheev <vadim@sable.krasnoyarsk.su> — 1998-02-11T08:19:48Z
Brett McCormick wrote: > > I don't see CREATE LANGUAGE in the grammar file... are you asking if > it is strictly compatible or if it uses the dynamic language interface? > there's no reason it shouldn't be compatible.. ... > DOH -- that's another question I meant to ask, as I noticed some > things in the new (6.3) code about it.. no, it isn't, it is hacked in > just like fmgr_dynamic is.. what do I need to know about the create > language interface.. any docs? ... > okay... yes it can co-exist with CREATE LANGUAGE as long as it is > coded into the server like fmgr_dynamic is. it will not function as a > CREATE LANGUAGE function. this is because all that this functionality > appears to do is associate a single function with a language. but it > does not pass the prosrc attribute (or probin for that matter) to the > function, so no matter what you say for as 'insert code here', it > never gets to the function, so the function has no idea what to do! Sorry: CREATE PLangTrusted PROCEDURAL LANGUAGE... PL handler function has to be created (via CREATE FUNCTION) before language creation.. After that you are able to do something like this (having PL/tcl): create function overpaid_2 (EMP) returns bool as ' if {200000.0 < $EMP(salary)} { return 't' } if {$EMP(age) < 30 && 100000.0 < $EMP(salary)} { return 't' } return 'f' ' language 'pltcl'; ^^^^^^^^^^^^^^^^ ^^^^^^^ in addition to built-in languages! Dynamic procedural language interface and support for TCL are implemented by Jan (wieck@sapserv.debis.de) - please contact to him to get more info (btw, there is create_language.l)... It would be nice to have support for perl... BTW, Mark, I don't see PLtcl in current sources. It would be nice to have it under contrib/pl or, even better, under src/pl (may be with flag USE_PLTCL in Makefile - like USE_TCL :), - with automatical installation into template database by initdb). Vadim -
Re: [HACKERS] rule system, perl and other good stuff
Jan Wieck <jwieck@debis.com> — 1998-02-11T08:20:59Z
Hi, > > > don't want to bring up a touchy subject, BUT... does the rule system > actually work, and if not, what are our plans? It would extend the > functionality of postgresql quite a bit and make it much more > attractive.. also I'm working on a modified version of pg with perl > language support. that's right, perl. so far I've got it to the > point where you can create perl functions (using anon sub refs) and > access your arguments and perform operations (from pg_operator) on > them. I'll get the patches together soon, once I add operator > overloading :) The rule system is wired up in some places. Especially it's impossible to have the values of the OLD and NEW tuples in UPDATE rules. But we have triggers that can do all the things rules might do. The function and trigger manager in 6.3 are prepared for things like functions in perl. There is a new command CREATE PROCEDURAL LANGUAGE. Look at the create_language manpage for details. Except for user defined type input-/output- functions anything can be done in a procedural language (functions, triggers, operators, aggregates). It would be very nice if your perl support makes use of the API defined for procedural languages. I've already written a call handler for the Tcl language that supports functions and trigger procedures written in Tcl (it's not in the contrib up to now, mail me if you want a developers copy). The procedural language support of the backend is a result from that work. As long as your perl stuff isn't able to handle things that cannot be done in C right now (like returning sets), there is absolutely no need to patch the backend again. And I currently work on a pure PL/pgSQL handler independent of other things like perl/Tcl. This one will also be implemented as a handler for the procedural language support. > > one more thing -- what about making the listen/notify interface > synchronous? what must be done? and... and... select foo[5:] for > elements 5 and onward in array foo.. > > In contrast I would vote for adding a really async functionality of the whole frontend/backend protocol. That would fit much better in the event driven world of graphical programs. Until later, Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) # -
Re: [HACKERS] rule system, perl and other good stuff
Jan Wieck <jwieck@debis.com> — 1998-02-11T08:45:21Z
Vadim wrote: > > > It would be nice to have support for perl... Asked for implementers sometimes :-) > > BTW, Mark, I don't see PLtcl in current sources. > It would be nice to have it under contrib/pl or, even better, under > src/pl (may be with flag USE_PLTCL in Makefile - like USE_TCL :), - > with automatical installation into template database by initdb). > > Vadim > Sure. Let me do some final tests (checking that PL/Tcl in the current version works with Tcl7.5 and Tcl8.0 with the same sources). Then I'll upload a tar for putting it into src/pl/pltcl or contrib/pl/pltcl (expecting the source directory in ../../src). There is a little test suite included into the directory. It checks triggers, functions, operators and aggregates. Since building is optional, I don't think that a real regression test is a good idea. Time is limited. So the USE_PLTCL part is up to you - sorry. Until later, Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) # -
Re: [HACKERS] rule system, perl and other good stuff
Jan Wieck <jwieck@debis.com> — 1998-02-11T08:47:32Z
> Sure. Let me do some final tests (checking that PL/Tcl in the > current version works with Tcl7.5 and Tcl8.0 with the same > sources). Then I'll upload a tar for putting it into > src/pl/pltcl or contrib/pl/pltcl (expecting the source > directory in ../../src). Ment ../../../src :-) -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) # -
Re: [HACKERS] rule system, perl and other good stuff
Vadim B. Mikheev <vadim@sable.krasnoyarsk.su> — 1998-02-11T08:57:13Z
Jan Wieck wrote: > > Sure. Let me do some final tests (checking that PL/Tcl in the > current version works with Tcl7.5 and Tcl8.0 with the same > sources). Then I'll upload a tar for putting it into > src/pl/pltcl or contrib/pl/pltcl (expecting the source > directory in ../../src). Nice! > > There is a little test suite included into the directory. It > checks triggers, functions, operators and aggregates. Since > building is optional, I don't think that a real regression > test is a good idea. Nice2!! > > Time is limited. So the USE_PLTCL part is up to you - sorry. ...Up to Mark (?) - sorry -:) Vadim
-
Re: [HACKERS] rule system, perl and other good stuff
Jan Wieck <jwieck@debis.com> — 1998-02-11T09:25:44Z
> > > okay... yes it can co-exist with CREATE LANGUAGE as long as it is > coded into the server like fmgr_dynamic is. it will not function as a > CREATE LANGUAGE function. this is because all that this functionality > appears to do is associate a single function with a language. but it > does not pass the prosrc attribute (or probin for that matter) to the > function, so no matter what you say for as 'insert code here', it > never gets to the function, so the function has no idea what to do! > > I must be missing something. Think so. Using the dynamic language interface, the handler is called by fmgr_pl() and one of the arguments is the Oid of the called PL function. So the handler has to do a system cache lookup on pg_proc (at least the first time this function is called) to get the prosrc attribute. The AS '...' text on CREATE FUNCTION will be found there for dynamic languages. It's handler specific what it expects in this attribute. For PL/Tcl it's the procedures body and it builds a Tcl proc around it after analyzing pg_proc and some other system catalogs. The Tcl proc's name contains the Oid, so overloading functions with different parameter types isn't a problem. A few minutes ago I sent down the PL/Tcl directory to this list. Look at it and reuse anything that might help to build PL/perl. I really hope that PL/perl and PL/Tcl appear in the 6.3 distribution. I'll do whatever I can to make this happen. > > On Tue, 10 February 1998, at 23:29:39, Brett McCormick wrote: > > > I don't see CREATE LANGUAGE in the grammar file... are you asking if > > it is strictly compatible or if it uses the dynamic language interface? > > there's no reason it shouldn't be compatible.. > > > > On Wed, 11 February 1998, at 14:26:23, Vadim B. Mikheev wrote: > > > > > One question: is your perl language support compatible with > > > new dynamic language interface (CREATE LANGUAGE etc) ? > > > > > > Vadim > > Until later, Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) # -
Re: [HACKERS] rule system, perl and other good stuff
Brett McCormick <brett@work.chicken.org> — 1998-02-11T09:38:08Z
I certainly was. It should be easy to switch over to using the dynamic PL mechanism. I hope to investing some time into it into the next few weeks to get it up to snuff. It will accept a package function or an anonymous sub ref as the AS clause src. Strings and integers are passed as scalars, and everything else is passed as a Postgres::Type. I was debating whether to make them Postgres::Type::datetime (to add type-specific methods in .pm files?) A scalar, array or Postgres::Type can be returned and will be cast automatically (if need be). On Wed, 11 February 1998, at 10:25:44, Jan Wieck wrote: > > Think so. Using the dynamic language interface, the handler > is called by fmgr_pl() and one of the arguments is the Oid of > the called PL function. So the handler has to do a system > cache lookup on pg_proc (at least the first time this > function is called) to get the prosrc attribute. The AS '...' > text on CREATE FUNCTION will be found there for dynamic > languages. It's handler specific what it expects in this > attribute. For PL/Tcl it's the procedures body and it builds > a Tcl proc around it after analyzing pg_proc and some other > system catalogs. The Tcl proc's name contains the Oid, so > overloading functions with different parameter types isn't a > problem. > > A few minutes ago I sent down the PL/Tcl directory to this > list. Look at it and reuse anything that might help to build > PL/perl. I really hope that PL/perl and PL/Tcl appear in the > 6.3 distribution. I'll do whatever I can to make this happen. > > > > > On Tue, 10 February 1998, at 23:29:39, Brett McCormick wrote: > > > > > I don't see CREATE LANGUAGE in the grammar file... are you asking if > > > it is strictly compatible or if it uses the dynamic language interface? > > > there's no reason it shouldn't be compatible.. > > > > > > On Wed, 11 February 1998, at 14:26:23, Vadim B. Mikheev wrote: > > > > > > > One question: is your perl language support compatible with > > > > new dynamic language interface (CREATE LANGUAGE etc) ? > > > > > > > > Vadim > > > > > > > Until later, Jan > > -- > > #======================================================================# > # It's easier to get forgiveness for being wrong than for being right. # > # Let's break this rule - forgive me. # > #======================================== jwieck@debis.com (Jan Wieck) # > >
-
Re: [HACKERS] rule system, perl and other good stuff
Jan Wieck <jwieck@debis.com> — 1998-02-11T09:41:27Z
BTW, recently I hacked around on the SETUID stuff and it wasn't that much to do. I renamed the obsolete and unsupported proistrusted attribute in pg_proc to proissetuid and made it default to false. Then I hacked some code into ExecMakeFunctionResult(), ExecCallTriggerFunc() and utils/init/miscinit.c and voila - setting proissetuid to true works for 'sql', 'C', and any PL functions called via a func node by the executor or triggerd. It does not work for input/output functions and I haven't checked about operators and aggregates. I don't think that types input/output functions need it and for the operators/aggregates it must be that easy too. What should the syntax for setting/unsetting proissetuid? ALTER FUNCTION funcname (args) (NO)SETUID looks good for me. But before doing anything here I think we should also be able to make a view setuid. I haven't thought much about that up to now. Any ideas how and where this could be done? Until later, Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) # -
Re: [HACKERS] rule system, perl and other good stuff
Marc G. Fournier <scrappy@hub.org> — 1998-02-11T14:08:58Z
On Wed, 11 Feb 1998, Jan Wieck wrote: > A few minutes ago I sent down the PL/Tcl directory to this > list. Look at it and reuse anything that might help to build > PL/perl. I really hope that PL/perl and PL/Tcl appear in the > 6.3 distribution. I'll do whatever I can to make this happen. Hrmmmm...I always love these "blanket" invitations :) I've installed it as src/pl/tcl...
-
Re: [HACKERS] rule system, perl and other good stuff
Jan Wieck <jwieck@debis.com> — 1998-02-11T14:28:08Z
> > On Wed, 11 Feb 1998, Jan Wieck wrote: > > > A few minutes ago I sent down the PL/Tcl directory to this > > list. Look at it and reuse anything that might help to build > > PL/perl. I really hope that PL/perl and PL/Tcl appear in the > > 6.3 distribution. I'll do whatever I can to make this happen. > > Hrmmmm...I always love these "blanket" invitations :) > > I've installed it as src/pl/tcl... > > CVSup'd that - but where's the test subdirectory gone? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) # -
Re: [HACKERS] rule system, perl and other good stuff
Marc G. Fournier <scrappy@hub.org> — 1998-02-12T01:28:16Z
On Wed, 11 Feb 1998, Jan Wieck wrote: > > > > On Wed, 11 Feb 1998, Jan Wieck wrote: > > > > > A few minutes ago I sent down the PL/Tcl directory to this > > > list. Look at it and reuse anything that might help to build > > > PL/perl. I really hope that PL/perl and PL/Tcl appear in the > > > 6.3 distribution. I'll do whatever I can to make this happen. > > > > Hrmmmm...I always love these "blanket" invitations :) > > > > I've installed it as src/pl/tcl... > > > > > > > CVSup'd that - but where's the test subdirectory gone? Check it again? I just checked here, and its been committed...yup, just checked the physical CVSROOT directories, and they are there too... Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org