[Monetdb-developers] XRPC syntax

Ying Zhang Y.Zhang at cwi.nl
Fri Oct 27 12:38:11 CEST 2006


On Tue, Oct 24, 2006 at 04:00:48PM +0200, Jens Teubner wrote:
> On Tue, Oct 24, 2006 at 03:40:16PM +0200, Ying Zhang wrote:
> 
> > Our intention is to allow an XQuery expression here (after "at"), but it
> > should be evaluated to a URILiteral.  How can I correct this rule to
> > express our intention?
> 
> This is a typing thing, and I've already implemented that.  Whatever the
> expression after "at" evaluates to, we try to cast it into a string.
> This is in line with how XQuery is defined elsewhere.
> 
> You cannot express such a restriction in your grammar, though.  This is
> a pure typing thing.

What is then the right definition of the grammar rule?

    XRPCCall ::= "execute" "at" "{" URILiteral "}" "{" FunctionCall "}"
    
or

    XRPCCall ::= "execute" "at" "{" ExprSingle "}" "{" FunctionCall "}"

(BTW, are the braces added correctly?)


> 
> > With or without '{' and '}' doesn't matter for me:)  So, if the braces
> > make it easier for parsing, we should then just adjust the syntax
> > definition.
> 
> Done already. :-)
> 
> > I'd like to mention that we need to check that the called function
> > belongs to an imported module, thus it should not be a built-in function
> > or a UDF which is in-line with the query.
> 
> I will have to think about how we can implement such a check most
> elegantly within Pathfinder.  I'm wondering about its usefulness,
> though.  I accept that we may want to restrict it to non-built-ins only.
> But is the import via a module a sensible restriction?  i

I think it does make sense to filter out XRPC calls to in-query UDFs.
If an in-query UDF is called with XRPC, the query just cannot be
executed, since we don't want to ship the function implementation in
XRPC request.  So if such a query is not rejected by the compiler, it
will eventually be rejected by the XRPC sender.

> I could easily
> create some module with some function definition and import it.  Still,
> the respective function would not be available at the XRPC target
> machine.  I think we cannot really check whether a target machine will
> actually implement a given function 
> (and if it does so with the same argument types).  
> So we will have a garbage in, garbage out situation
> always.  Does it then make sense to do this very special check at all?

Maybe we should put even more restriction on the imported module, such
as we can require that the imported module should be available in a
location which is accessible via the HTTP protocol.  This way, we know
it for sure that both the XRPC client and the server can access the
module definition file (provided there is not further authentication
restriction of accessing the file), and both the client and the server
access the *same* module definition file, so the argument types should
be the same (right?).

Is it difficult to implement this restriction?

Jennie

> 
> Jens
> 
> -- 
> Jens Teubner
> Technische Universitaet Muenchen, Department of Informatics
> D-85748 Garching, Germany
> Tel: +49 89 289-17259     Fax: +49 89 289-17263
> 
> SQL0437W  Performance of this complex query may be sub-optimal.
> Reason code: "3".  SQLSTATE=01602
>                          -- IBM DB2 V7.1 Warning Message




More information about the developers-list mailing list