[EMAIL PROTECTED] (Tom Lane) wrote
Ross J. Reedstrom [EMAIL PROTECTED] writes:
I agree that a 'trimmed' query is likely to be useless, but the idea of
printing the query on ERROR is a big win for me:
Certainly. I think though that an on-or-off GUC option is sufficient.
We don't need a
[EMAIL PROTECTED] (Bruce Momjian) wrote
Sir-* does have a point. A valid host in pg_hba.conf can cause DOS by
just connecting over and over, but allocating almost all of the memory
on the machine would affect other applications running on the machine,
even non-networked applications, as
[EMAIL PROTECTED] (Florian Weimer) wrote
[EMAIL PROTECTED] writes:
if you are going to be passing any user input to the database, you
must/should validate in some manner before blindly passing it to the db.
The db can and should guarantee data integrity, but the database cannot
read
[EMAIL PROTECTED] (Curt Sampson) wrote in
On Mon, 19 Aug 2002 [EMAIL PROTECTED] wrote:
$input = user'name;
INSERT INTO db (name) VALUES ('$input');
will fail because the ' in the input needs to be escaped with a
backslash.
It will fail because you're doing this a very, very, very bad
[EMAIL PROTECTED] (Greg Copeland) wrote
Time and time again I've read what basically amounts to, ...if someone
can crash it it's because someone is stupid enough to allow someone to
be able to do it in the first place... Maybe you're right. After all,
if core developers continue to turn a
[EMAIL PROTECTED] (Florian Weimer) wrote
Alvar Freude [EMAIL PROTECTED] writes:
What about checking the input for backslash, quote,
and double quote (\')? If you are not taking care of those in
input then crashing the backend is going to be the least of your
worries.
with Perl and
[EMAIL PROTECTED] (Tom Lane) wrote
* If a connection request has a username with a trailing '@' (and no
embedded '@'), then the '@' is stripped and connection proceeds.
* Otherwise, '@dbname' is appended to the given username and
connection proceeds.
snip
It might be worth recalling the
[EMAIL PROTECTED] (Bruce Momjian) wrote
I know the trailing @ is ugly, but it prevents surpises when connecting
to the database.
if you would make the magic character a variable then perhaps you could
prevent the ugly... if/when you turn off the feature, you could set the
Summary:
1. The current implementation is broken.
2. We have no proper description of how a fixed implementation
should work.
3. It's hard to fix the current implementation without such a
description.
4. Thus, we are in other messages here trying to work
OK, the vote is not shifting from '.' to ''. Is that how we want to
go? I like the pg_user enhancement. Marc, comments? This was your
baby.
Would it be hard to setup an internal PG variable for the actual character
to be used?
---(end of
[EMAIL PROTECTED] (Bruce Momjian) wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I don't know where else to go with the patch at this point. I
think increasing the number of 'global' users is polluting the
namespace too much,
Why? If the installation needs N global
[EMAIL PROTECTED] (Florian Weimer) wrote in
[EMAIL PROTECTED]:">news:[EMAIL PROTECTED]:
Gavin Sherry [EMAIL PROTECTED] writes:
Yes, but if you just check that the date given by the user matches the
regular expression [0-9]+-[0-9]+-[0-9]+, it's still possible to
crash the backend.
12 matches
Mail list logo
