On Sat, Apr 26, 2008 at 9:58 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> IIRC there was some discussion recently of providing a mode in which
> the server would reject PQexec strings containing more than one query.
> I didn't care for it much at the time, but I think it would provide
> most of t
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> Agreed. My point was that to do what the OP wants, wouldn't it make
> more sense to just lobotomize libpq so it doesn't understand anything
> but prepared queries.
I doubt that that particular lobotomization accomplishes much in
comparison to the pena
On Sat, Apr 26, 2008 at 9:42 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Scott Marlowe" <[EMAIL PROTECTED]> writes:
> > Wouldn't it be much simpler to have a version of the libpq client lib
> > that only understands prepared queries?
>
> You could do that, but there's still no way for it to know
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> Wouldn't it be much simpler to have a version of the libpq client lib
> that only understands prepared queries?
You could do that, but there's still no way for it to know exactly how
the submitted query was constructed. This would block off the types
On Sat, Apr 26, 2008 at 3:32 PM, Thomas Kellerer <[EMAIL PROTECTED]> wrote:
> Thomas Mueller wrote on 26.04.2008 18:32:
>
> > Literals can still be used when using query tools, or in applications
> considered 'safe'.
> >
> I fail to see how the backend could distinguish between a query sent by a
>
Thomas Mueller wrote on 26.04.2008 18:32:
Literals can still be used when using query tools, or in applications considered 'safe'.
I fail to see how the backend could distinguish between a query sent by a query
tool and a query sent by an "application".
Thomas
--
Sent via pgsql-sql mailing l
On Sat, Apr 26, 2008 at 1:19 PM, Thomas Mueller
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> > > The 'ALLOW_LITERALS NONE' mode is enabled by the developer itself, or
> > > by an administrator.
> > then it solves nothing...
> > what if the developer never SET ALLOW_LITERALS NONE
>
> As I have said, the
Hi,
> > The 'ALLOW_LITERALS NONE' mode is enabled by the developer itself, or
> > by an administrator.
> then it solves nothing...
> what if the developer never SET ALLOW_LITERALS NONE
As I have said, the 'ALLOW_LITERALS NONE' mode is enabled by the
developer itself, or by an administrator. T
Hi,
> I think you missed April Fool's Day...
This is absolutely not an April Fool idea :-) I must have made a bad
job explaining my idea.
> This is just silly, as it makes life impossibly painful for users
You mean developers? No, developers should use parameterized queries anyway.
> (const
On Sat, Apr 26, 2008 at 11:32 AM, Thomas Mueller
<[EMAIL PROTECTED]> wrote:
>
> The 'ALLOW_LITERALS NONE' mode is enabled by the developer itself, or
> by an administrator.
then it solves nothing...
what if the developer never SET ALLOW_LITERALS NONE or
maybe i can inject "select * from tab where
"Thomas Mueller" <[EMAIL PROTECTED]> writes:
> SET ALLOW_LITERALS NONE;
I think you missed April Fool's Day...
This is just silly, as it makes life impossibly painful for users
(constants are hardly a useless part of SQL) and it doesn't really
plug any holes. As an example:
select * fro
Hi,
As you know, "SQL injection" is the main security problem of databases today.
I think I have a solution: 'disabling literals'. Or you may call it
'enforcing the use of parameterized statements'. This means that SQL
statements with embedded user input are rejected at runtime. My
solution goes
12 matches
Mail list logo
