"Gurjeet Singh" <[EMAIL PROTECTED]> writes:
> In the plan below, we can see that the optimizer is sorting an already
> sorted result. It seems to forget the sort order across the UNIQUE node. My
> question is, do we make any attempts in the optimizer to remember the sort
> order of a result, to avo
In the plan below, we can see that the optimizer is sorting an already
sorted result. It seems to forget the sort order across the UNIQUE node. My
question is, do we make any attempts in the optimizer to remember the sort
order of a result, to avoid any further sorting on same sort-key? If not,
can
Greg,
> Did you guys miss Tom's comment up-thread? Postgres already does this if
> you use PQExecParams().
Keen. Now we just need to get the driver developers to implement it. I
imagine Java does.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
--
Sent via pgsql-hackers mailing list (pgsql-h
"Josh Berkus" <[EMAIL PROTECTED]> writes:
>> (I sort of like the
>> suggestion up-thread, myself, which is to have a GUC that disables
>> multi-statement commands. That'd probably cover a huge number of
>> cases, and combined with some sensible quoting rules in client
>> libraries, would quite po
On Wed, Apr 30, 2008 at 1:48 AM, Thomas Mueller <
[EMAIL PROTECTED]> wrote:
> Hi,
>
> For PostgreSQL the 'disable literals' feature would be great
> publicity:
>
>
'publicity' is something this community does not crave for, at least not
feature wise. If that were the case we would have had a milli
On Tue, 29 Apr 2008 22:18:48 +0200 Thomas Mueller wrote:
> For PostgreSQL the 'disable literals' feature would be great
> publicity: PostgreSQL would be the first only major database that has
> a good story regarding SQL injection. Yes it's not the magic silver
> bullet, but databases like MS SQL
> (I sort of like the
> suggestion up-thread, myself, which is to have a GUC that disables
> multi-statement commands. That'd probably cover a huge number of
> cases, and combined with some sensible quoting rules in client
> libraries, would quite possibly be enough.)
MySQL did this already.
--
[I know, I know, bad form]
On Tue, Apr 29, 2008 at 04:55:21PM -0400, Andrew Sullivan wrote:
> thinking they have to worry about that area of security at all. I
> think without a convincing argument that the proposal will even come
> close to covering most SQL injection cases, it's a bad idea.
To
Thomas,
> For PostgreSQL the 'disable literals' feature would be great
> publicity: PostgreSQL would be the first only major database that has
> a good story regarding SQL injection. Yes it's not the magic silver
> bullet, but databases like MS SQL Server, Oracle or MySQL would look
> really bad.
On Tue, Apr 29, 2008 at 04:33:01PM -0400, Andrew Dunstan wrote:
> Moreover, it seems unlikely that it will even cover the field. A partial
> cloak might indeed be worse than none, in that it will give some developers
> an illusion of having security.
I think this is a really important point, an
Thomas Mueller wrote:
Forbidding literals will break absolutely every SQL-using application on the
planet
Well, it's optional. If a developer or admin wants to use it, he will
know that it could mean some work. Even if the feature is not enabled,
it's still good to have it. And using co
Hi,
For PostgreSQL the 'disable literals' feature would be great
publicity: PostgreSQL would be the first only major database that has
a good story regarding SQL injection. Yes it's not the magic silver
bullet, but databases like MS SQL Server, Oracle or MySQL would look
really bad.
> [literals..
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>> I'm thinking is that we should get rid of the ::float8 decoration too,
>> and thereby be able to revert some of the ugly code added elsewhere such
>> as guc.c.
> Hmm, I'm not sure but I think the typecast is needed in the guc.c cod
Tom Lane escribió:
> [EMAIL PROTECTED] (Alvaro Herrera) writes:
> > Remove typename from A_Const.
>
> I'm thinking this could be cleaned up further. The patch as applied
> removes the ::int4 typename decoration that had been inserted by
> makeIntConst(), while leaving in place the ::float8 decora
* Gregory Stark <[EMAIL PROTECTED]> [080429 14:20]:
> "Aidan Van Dyk" <[EMAIL PROTECTED]> writes:
>
> > That said, though *I* like the idea (and since I develop against
> > PostgreSQL 1st and use params for my queries I would consider it a nice
> > tool to "keep me honest"), I can easily see that
Hi Martijn,
> > The problem is not only quotes. The problem is all kinds of user
> > input. For example: sql = "SELECT * FROM ORDERS WHERE ORDER_ID = " +
> > orderId; This is not a problem if orderId is a number. But what if
> > it's a String? For example "1 AND (SELECT * FROM USERS WHERE
> >
For example, some applications need to replace whole phrases:
$criteria = "WHERE $var1 = '$var2'"
This is a very common approach for dynamic search screens, and really not
covered by placeholder approaches.
Python, again :
params = {
'column1': 10,
'column2': "a st'rin
> If you're going to ask people to do significant revision of their
> apps to gain security, they're going to want it to work no matter
> what database they run their apps against. This is why you need
> a client-side solution such as tainting.
Or if people are going to re-write their applicatio
"Aidan Van Dyk" <[EMAIL PROTECTED]> writes:
> That said, though *I* like the idea (and since I develop against
> PostgreSQL 1st and use params for my queries I would consider it a nice
> tool to "keep me honest"), I can easily see that the cost/benefit ratio
> on this could be quite low and make i
[EMAIL PROTECTED] (Alvaro Herrera) writes:
> Remove typename from A_Const.
I'm thinking this could be cleaned up further. The patch as applied
removes the ::int4 typename decoration that had been inserted by
makeIntConst(), while leaving in place the ::float8 decoration inserted
by makeFloatConst
Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
> Peter Eisentraut wrote:
> > Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
> > > We do look at COLUMNS if the ioctl() fails, but not for file/pipe
> > > output.
> >
> > This is quite a useless complication. Readline uses exactly the same
> >
Magnus,
Please, take a look at my implementation of stat().
It has at least two advantages: it's faster and doesn't have a bug with
local-to-UTC time conversion that native msvc's stat() has.
Maybe it will be useful.
Thank you.
-Original Message-
From: Magnus Hagander [mailto:[EMAIL PRO
* Tom Lane <[EMAIL PROTECTED]> [080429 10:59]:
> "Tom Dunstan" <[EMAIL PROTECTED]> writes:
> > Damn, am I the only person who likes the idea?
>
> Just about. The reason that this idea isn't going anywhere is that its
> cost/benefit ratio is untenably bad. Forbidding literals will break
> absolut
Tino Wildenhain wrote:
Hi,
In C the best practice is to use #define for constants. In C++ you
have 'const', in Java 'static final'. Unfortunately the 'named
constant' concept doesn't exist in SQL. I think that's a mistake. I
suggest to support CREATE CONSTANT ... VALUE ... and DROP CONSTANT
.
"Tom Dunstan" <[EMAIL PROTECTED]> writes:
> Damn, am I the only person who likes the idea?
Just about. The reason that this idea isn't going anywhere is that its
cost/benefit ratio is untenably bad. Forbidding literals will break
absolutely every SQL-using application on the planet, and in many
Hi,
In C the best practice is to use #define for constants. In C++ you
have 'const', in Java 'static final'. Unfortunately the 'named
constant' concept doesn't exist in SQL. I think that's a mistake. I
suggest to support CREATE CONSTANT ... VALUE ... and DROP CONSTANT
..., example: CREATE CONSTA
"dv @ nabble" <[EMAIL PROTECTED]> writes:
> From: "Tom Lane" <[EMAIL PROTECTED]>
>> If you're not joining to the function result, and you don't need the
>> ability to determine its result type on the fly, you could declare it
>> as returning a specific rowtype and then call it in the targetlist:
>>
On Tue, Apr 29, 2008 at 12:25 AM, Thomas Mueller
<[EMAIL PROTECTED]> wrote:
> What do you think about it? Do you think it makes sense to implement
> this security feature in PostgreSQL as well? If not why not? Does
> PostgreSQL have another solution or plan to solve the SQL injection
> problem
PontoSI - Consultoria, Informática e Serviços LDA wrote:
I'm writing a small program to recover specific tables from a severely
crippled database, and while I'm able to identify most fields on a hex
dump of the table file, there are several 'gaps' (probably headers and
footers and/or additional
On Tue, Apr 29, 2008 at 02:19:24PM +0100, "PontoSI - Consultoria, Informática e
Serviços LDA" wrote:
> I'm writing a small program to recover specific tables from a severely
> crippled database, and while I'm able to identify most fields on a hex
> dump of the table file, there are several 'gaps
"Thomas Mueller" <[EMAIL PROTECTED]> writes:
> Also, programming languages such as Java don't support tainting. And it's
> again in the hand of the developer to use it, not use it, or use it in the
> wrong way. There should be a way for an admin to enforce using it, and using
> it correctly.
I be
Hi,
I'm writing a small program to recover specific tables from a severely
crippled database, and while I'm able to identify most fields on a hex
dump of the table file, there are several 'gaps' (probably headers and
footers and/or additional info) that I can't identify. Where can I find
docu
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>>
>> > We do look at COLUMNS if the ioctl() fails, but not for file/pipe
>> > output.
>>
>> Yeah, it looks like your most recent patch still has the bug that if the user
>> specifie
zero developer pain
Actually it's not zero pain, but the main problem is: there is no way
to enforce using it.
Sure, there is no way to enforce it (apart from grepping the source for
pg_query() and flogging someone if it is found), but is it really
necessary when the right solution is eas
On Tue, Apr 29, 2008 at 01:37:37PM +0200, Thomas Mueller wrote:
> > any literal (i.e. not just strings) can be quoted, think of dates in
> > queries.
>
> The problem is not only quotes. The problem is all kinds of user
> input. For example: sql = "SELECT * FROM ORDERS WHERE ORDER_ID = " +
> order
Hello,
I want to collect various statistics like time taken, number of context
switches, page faults etc.. for a query being run. postgres.c contains lots of
getrusage related things.
Is there any way to calculate all the things without writing any custom code ?
Thanks and regards,
Suresh
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > Gregory Stark wrote:
> >> > Now, we could get fancy and honor $COLUMNS only in non-interactive mode,
> >> > but that seems confusing.
> >>
> >> We could always read COLUMNS early on before readline is initialized and
> >> s
Peter Eisentraut wrote:
> Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
> > We do look at COLUMNS if the ioctl() fails, but not for file/pipe
> > output.
>
> This is quite a useless complication. Readline uses exactly the same ioctl()
> call to determine the columns, so if ioctl() were to f
Hi,
> Meredith's libdejector
1) The last activity was 2005-12-17 :-(
2) From the docs: "the techniques used ... are ... being explored for
patentability".
3) The tool validates the SQL statement. This is not required when
using parameterized queries.
4) An 'exemplar' query is required for each qu
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Heikki Linnakangas" <[EMAIL PROTECTED]>
Cc: "dv @ nabble" <[EMAIL PROTECTED]>; "pgsql-hackers list"
Sent: Monday, April 28, 2008 5:07 PM
Subject: Re: [HACKERS] SRF in SFRM_ValuePerCall mode
"Heikki Linnakangas" <[EMAIL P
"Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
>> We do look at COLUMNS if the ioctl() fails, but not for file/pipe
>> output.
>
> This is quite a useless complication. Readline uses exactly the same ioctl()
> call to determine the columns, so
OK,
Thank you for the explanation, I hope this will be implemented in future.
We will try and find a workaround to this issue until then.
Denis
- Original Message -
From: "Heikki Linnakangas" <[EMAIL PROTECTED]>
To: "dv @ nabble" <[EMAIL PROTECTED]>
Cc: "pgsql-hackers list"
Sent: Mo
Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
> We do look at COLUMNS if the ioctl() fails, but not for file/pipe
> output.
This is quite a useless complication. Readline uses exactly the same ioctl()
call to determine the columns, so if ioctl() were to fail, then COLUMNS would
be unset or
Am Montag, 28. April 2008 schrieb Martijn van Oosterhout:
> As one of those confused, it would be really nice if someone could
> summarise it all on a wiki page that we can point people to.
http://wiki.postgresql.org/wiki/TrackerDiscussion
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
On Tue, 29 Apr 2008 01:03:33 +0200, Brendan Jurd <[EMAIL PROTECTED]> wrote:
On Tue, Apr 29, 2008 at 7:00 AM, PFC <[EMAIL PROTECTED]> wrote:
I have found that the little bit of code posted afterwards did
eliminate
SQL holes in my PHP applications with zero developer pain, actually it
is
MOR
45 matches
Mail list logo