On Tue, 18 Nov 2014 12:06:02 +0000
Simon Slavin <slav...@bigfraud.org> wrote:

> > my requirement, which is using a
> > table name as a variable
> 
> This is deliberately made very difficult in SQL.  I think it's for
> security reasons.

That may be part of it, but It's really all about values.  

SQL has value semantics.  That there are no pointers is a deliberate
choice, made because value semantics are easier to reason about.  

A table is an SQL variable; the name of a table is  a name of a
variable. Not many languages interpolate variable names the way e.g.
Perl does.  When you think of it that way, it's unsurprising that

        select T = 'foo';
        select count(*) from tableof(T);

doesn't work, nor does anything similar.  Even though it doesn't look
like a C pointer, T above is a pointer in semantic terms: it is not a
table, but putatively a "tablename variable", something that holds the
name of a table (which is SQL is the only way to reference any
variable).  

Given the obscure SQL I've seen, I'm glad not to deal with that kind of
indirection.  

IMO the most confusing aspect is parameterized queries, which IIRC
aren't defined by the SQL standard (not that that matters much).  Once
you can replace data with @param or similar, it seems a small step to
parameterize metadata, too.  But the designers were thinking along
functional lines, 

        table = function(parameter)

and again, within that framework, it's pretty rare to find a language
in which the parameter could itself be the name of a variable.  

Note that parameterized metadata would add no value to SQL per se.
Parameterized data yields efficiency and even accuracy gains because
numeric (and other nontext) data can be sent to the server in binary
form without being converted to strings. (In that way parameterized
queries mirror plain old SELECT, which returns binary data.)  Metadata
on the other hand are always text and can be readily parameterized
with any macro processor without reference to datatypes in the
database.  

--jkl
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to