Обсуждение: rule system, perl and other good stuff
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..
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
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
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
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
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
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) #
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) #
> 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) #
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
>
>
> 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) #
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) #
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) # > >
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...
>
> 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) #
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