in reply to How to interpolate sql-output

Just do it like this:   (a sketch ... not code-writing services)

First, write your query to use a placeholder:
select foo.id as key,(select value from foo_data where aktivity is true
and foo.id=foo_id and key='name'
order by id desc limit 1) as value
from foo where id!=?

Now, when you’t called $dbh->prepare($sql); with this SQL string to get your statement-handle, $sth, call $dbh->execute('xyzzy';, which, as you can see, provides a @bind_values array as shown in the perldoc.   The first value in the array (in this case, 'xyzzy', will be provided to the database engine so that it will use that value in place of the first placeholder '?' and so-on.   (It doesn’t do a textual substitution ... the SQL string is compiled only once, but it has “an input-variable,” so to speak.   The question-mark is not quoted:   it is not a “literal string.”

You should n-e-v-e-r construct an SQL string yourself, using any input provided by ... well ... anyone.   This is what placeholders are for.   It neatly avoids the Bobby Tables problem.

Notice also that, having prepared the statement-handle, you can execute() it as many times as you want to, providing different bind-parameters each time.   This is efficient, because the SQL engine builds its execution-plan for the query only once, then re-executes it multiple times.

Replies are listed 'Best First'.
Re^2: How to interpolate sql-output
by Seq (Novice) on Jan 14, 2015 at 22:33 UTC

    I know placeholders and those hold their place quite well..
    Unfortunately I haven't seen any real performance or other improves with those. (Only in repetitive task.)
    Those are good, if you want in some strange reason to put binary-stuff to db or do same insert many times etc.

    Usually quote is enough with a bit of sanity-check like ~/^\d+/.
    Ofc one have to be aware of sql-injection and not only depend audition where someone else is trying to hack into system.

    Actually I made once geocaching-mystery, which includes sql-injection and it was quite hard, cause I learnt to avoid those.

    This approach, which I chosen is a test, in which I try to different direction.
    Ofc I could use pre-made queries with placeholder and all that jazz, but clients needs are changing and I can't foresee any of those different variations they might need.
    I'll be ending to do lots of different variations of queries beforehand and when need arices I have to do the needed one, cause I cannot anticipate their needs exactly.

    I'll be quite sure, that only I'll do those queries.
    It'll be quite like changing code afterwards, but quicker and easier.

    And yes, access to those queries is quite limited.
    Ofc it's hackable, cause everything is, but then whole system is compromised, like source-code and database.