<div dir="ltr"><div>I'm happy to hear that there is some syntactic sugar involved here, which is what I had been hoping. I may have overlooked where this syntactic sugar was mentioned in the manual or demos, so I'm still a bit unsure how it works.</div><div><br></div><div>Similar to the function you wrote, my attempt to extend the Crud demos to provide a <select> element to allow users to edit foreign-key fields also involves a table parameter. I had also been noticing that using a functor provides a convenient way to bind local table variables, so I will try to use this approach.</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 3, 2015 at 1:29 AM, Ziv Scully <span dir="ltr"><<a href="mailto:ziv@mit.edu" target="_blank">ziv@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I haven't read this fully, but you are indeed correct in that there is a relationship between the identifier [tab], which is a value of type [sql_table _ _] (where the two type arguments are filled in with something), and [Tab], which is an ordinary (type-level) value of kind [Name].<div><br></div><div>I believe this special relationship is only for SQL syntactic sugar in SELECT statements. When constructing the queries using the raw functions in Basis (see lib/ur/basis.urs), you can associate names with tables however you like. For UPDATE and DELETE statements, there's always only one table, and its associated name is hard-coded as [#T], though if you use the syntactic sugar this name never appears.</div><div><br></div><div>I spent a lot of time digging into basis.urs because I wanted to write the a function that abstracts the pattern</div><div><br></div><div>SELECT fields FROM table WHERE table.KeyColumn = {[keyValue]}</div><div><br></div><div>and couldn't do it with the syntactic sugar. </div></div></blockquote><div><br></div><div><br></div></div></div></div>