Re: eval function
От | Merlin Moncure |
---|---|
Тема | Re: eval function |
Дата | |
Msg-id | CAHyXU0wOUm=XxWtpocumJMF4gHKjk0kru4JW07cDUTFKoYqTJA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: eval function ("David Johnston" <polobo@yahoo.com>) |
Ответы |
Re: eval function
|
Список | pgsql-general |
On Thu, Jul 28, 2011 at 10:08 AM, David Johnston <polobo@yahoo.com> wrote: > > Merlin Moncure <mmoncure@gmail.com> writes: >> Couple points: >> *) why a special case for boolean values? > > That seemed weird to me too ... > >> *) this should be immutable > > What if the passed expression is volatile? Better to be safe. > > --------------------------------- > > At best, based upon the example using "current_timestamp()", you could only > mark it as being stable, right? > > Also not mentioned; what risk is there of this function being hacked? It > places the supplied data within a "SELECT (....) AS column_alias" structure > so it seems to be pretty safe but can you devise a string that would, say, > delete data or something similar. I would expect the following: '1); DELETE > FROM table; SELECT (2' to be dangerous. What functions would you use to > make the input string safe? Does "quote_literal()" plug this hole? This function is an absolute no-go if the string literal is coming from untrusted source, and any robust defenses would ruin the intended effect of the function. There are a number of nasty ways you can (at minimum) DOS your database by allowing arbitrary sql. For example, using generate_series() and advisory_locks you can exhaust lock space. merlin
В списке pgsql-general по дате отправления: