[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'
[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
>
[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 tu
[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, v
[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.
>
[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.
> 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
PGSQL_STUPI
[EMAIL PROTECTED] (Vince Vielhaber) wrote
> Here we go again. I thought you just said that the @ wouldn't be
> something a user would have to do. I understood that to be any user.
> It's back to ugly again.
>
> Vince.
If it means anything to you, I agree that it should be a configure/compile
[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
> 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 broadcast)--
> 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 tryin
[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 bac
13 matches
Mail list logo
