[PD] [psql] object hand-holding
mjmogo at gmail.com
Fri Dec 21 22:09:40 CET 2007
On 12/21/07, Mathieu Bouchard <matju at artengine.ca> wrote:
> On Thu, 13 Dec 2007, Mike McGonagle wrote:
> > As someone who has never really used Placeholders, the only sorts of
> > things that I can see them being useful for are when you need to do a
> > lot of inserts or deletes, or for other statements that will be executed
> > repeatedly. From what I am gathering by these discussions is that the
> > useage of placeholders allows the SQL statement to be "compiled" and
> > then with each execution of the statement, the values of the
> > placeholders are substituted.
> You seem to think of placeholders as something extra that you necessarily
> add for improving the speed because inserting text within SQL seems
> perfectly normal. This is not the case. From another perspective,
> everything that can be abstracted out ought to be abstracted out, and that
> means that you don't want to touch SQL syntax with your data, you want to
> think of a SQL statement as a function that you call in your main
> programming language, you don't want to have to do type conversions and
> quoting because that's an aspect of SQL and not of your main programming
Well, as I have said, I have not used the placeholder stuff much, and a
friend of mine who is one of the lead programmers for a credit bureau here
in Chicago says that his company doesn't really use them all that often.
> This might be one reason you don't see them all that often in PHP, I would
> > imagine that PHP doesn't really do a whole bunch of repetitive stuff.
> So far, all successful attacks on my server has been through PHP scripts
> that don't quote things properly. For example, embedding text directly
> into email headers without regard for email syntax.
Actually, I still don't seem to understand the rules for quoting things, as
it appears that every database does it differently. SQLite uses double
quotes for somethings, and single quotes for others, and then you got MySQL
which seems to quote things differently.
>From this link, you will notices that almost every database seems to do
things A LITTLE differently.
As it stands right now, I am leaving the quoting up to the user who
constructs the SQL.
> This idea of doing this to make this more PD-like I think would be a waste
> > of time, as SQL is pretty simple and a LOT of people already know it.
> > create another "language"?
> Because that other language would be more integrated with pd itself and
> integration is good, if it really makes things feel more familiar. You can
> witness the importance of this by looking at how much people avoid using
> other programming languages with pd (beyond the difficulties in compiling
> externals and distributing patches that use code like that).
My comment here was in creating the SQL statement. I was hoping not to
create a version of SQL that was specific to PD, that is what I meant by a
waste of time.
The big downside of integration is that it usually does not cover the
> whole feature set of what is being wrapped, and especially not nonstandard
And then you add to this the differences between different databases. While
I hope to be able to swap one database for another, I don't know if it would
be possible to do that without having to tweak the SQL statements that were
> At the same time, should our external be on the look out for these sorts
> > of things? One of the original ideas was to not give the external any,
> > if at all, knowledge of SQL. Meaning, it wouldn't "parse" the SQL, nor
> > would it try to do any generation of SQL. It just expects that the user
> > is HONEST (that is what these concerns over Injection are, right), and
> > the SQL they entered is what they meant.
> You can't assume that the user is honest, because when you do, you also
> assume that the user does not make mistakes when including input from
> other sources that can't be assumed to be honest.
Well, this is one of those reasons why I am starting with using SQLite, I
think it would be much easier than working with a networked database. And if
someone is being 'dishonest', then they are only effecting themselves.
> While we can try to protect against various things, those that want to
> > be malicious will do so anyway.
> This is not true. Every step is important in making it more difficult for
> abuse to happen.
Well, if we are allowing these people to construct their own SQL and they
are building their own stuff, just how can we stop them from being
malicious? I mean, the only real way to stop this completely, is to not
produce a network version of this, and only deal with standalone.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list