Bruce Momjian wrote:
>
> Your patch has been added to the PostgreSQL unapplied patches list at:
>
> http://candle.pha.pa.us/cgi-bin/pgpatches
>
> I will try to apply it within the next 48 hours.
>
> > It has come to our attention that many applications which use libpq
> > are vulnerabl
> Its been much much too long since I've upgraded Majordomo2 on the server,
> so this is the last email I'm sending out prior to upgrading her today ...
> if anyone notices the lists go suddenly quiet, or the way it works
> changing, please let me know ...
>
> My main worry is that in the past 6+
Doh - sorry about these hideously late posts. I think my mail queue has
been clogged up for a while!
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher
> Kings-Lynne
> Sent: Monday, 23 July 2001 10:34 AM
> To: Tom Lane
> Cc: Hackers
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Are you sure? I thought all that autocommit meant was that a statement that
> is not enclosed within a begin/commit is automatically committed after it is
> run. So, in the this case all three queries will be independent, unless the
> firs
Ok, I misudnerstood, I had long included my own escaping function in
programs that used libpq, I thought the intent was to make escaping happen
automatically..
Thanks!
-Mitch
- Original Message -
From: "Alex Pilosov" <[EMAIL PROTECTED]>
To: "Mitch Vincent" <[EMAIL PROTECTED]>
Cc: <[EMAI
Are you sure? I thought all that autocommit meant was that a statement that
is not enclosed within a begin/commit is automatically committed after it is
run. So, in the this case all three queries will be independent, unless the
first statements is a 'begin;' and the last is a 'commit;'...
Chri
Doh! Guess that makes our work on contrib/fulltextindex a waste of time,
huh?
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Bruce Momjian
> Sent: Friday, 10 August 2001 12:34 AM
> To: Oleg Bartunov
> Cc: Pgsql Hackers; [EMAIL PROTECTED]
>
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > I'm playing around with the Full Text Indexing module, and I notice that
> > it's case-sensitive. This seems to be pretty useless to me -
> especially for
> > my application. I wonder if there'd be any objections to me
> modifying it to
"Mitch Vincent" <[EMAIL PROTECTED]> writes:
> Perhaps I'm not thinking correctly but isn't it the job of the application
> that's using the libpq library to escape special characters?
Yes, it is.
> I guess I don't see a down side though, if it's implemented
> correctly to check and see if chara
It is. Application is responsible to call PGescapeString (included in the
patch in question) to escape command that may possibly have user-specified
data... This function isn't called automatically.
On Thu, 30 Aug 2001, Mitch Vincent wrote:
> Perhaps I'm not thinking correctly but isn't it the j
Perhaps I'm not thinking correctly but isn't it the job of the application
that's using the libpq library to escape special characters? I guess I don't
see a down side though, if it's implemented correctly to check and see if
characters are already escaped before escaping them (else major breakage
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
> It has come to our attention that many applications which use libpq
> are vulnerable to code insertion attacks in strings
> Florian Weimer <[EMAIL PROTECTED]> writes:
>
> > We therefore suggest that a string escaping function is included in a
> > future version of PostgreSQL and libpq. A sample implementation is
> > provided below, along with documentation.
>
> We have now released a description of the problems wh
On Thu, 30 Aug 2001 19:56:53 +0200 (CEST), you wrote:
>Rene Pijlman writes:
>> If autocommit is _enabled_ and S1;S2;S3 is send to the database,
>> what exactly is the behaviour of the backend? For example, what
>> happens if S1 succeeds, S2 fails and S3 would succeed?
>
>All three commands are exe
Rene Pijlman writes:
> If autocommit is _enabled_ and S1;S2;S3 is send to the database,
> what exactly is the behaviour of the backend? For example, what
> happens if S1 succeeds, S2 fails and S3 would succeed?
All three commands are executed in a single transaction. So if S2 fails,
S3 would no
ignore, just making sure it works ...
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Its been much much too long since I've upgraded Majordomo2 on the server,
so this is the last email I'm sending out prior to upgrading her today ...
if anyone notices the lists go suddenly quiet, or the way it works
changing, please let me know ...
My main worry is that in the past 6+ months, so
On Thu, 30 Aug 2001, Jon Lapham wrote:
> Okay, thanks, dropping and recreating the rule worked.
>
> After thinking a bit about this, it would seem that the 'problem' is
> that I was *able* to drop a table that had rules referencing it. Would
> it be possible to either not allow this, or to is
Jon Lapham writes:
> I'm receiving the following error message:
> ERROR: Relation "log" with OID 3694127 no longer exists
As a general rule, this won't work in PostgreSQL:
CREATE TABLE foo (...);
CREATE RULE bar ... ON foo ...; # view, trigger, etc.
DROP TABLE foo (...);
CREATE TABLE foo (...)
We're discussing an implementation of JDBC's
Statement.executeBatch() on the pgsql-jdbc list. The idea is to
send multiple semicolon separated statements in one call to the
backend. The purpose of this feature is of course a performance
improvement, since it executes multiple (non-select) statemen
On Wed, Aug 29, 2001 at 11:15:08AM +0200, Markus Wagner wrote:
> Hi,
>
> we need to control database changes within BEFORE triggers.
> There is no problem with triggers called by update, but there is
> a problem with triggers called by insert.
>
> We strongly need to know the oid of a newly inse
> If full SQL92 implementation of INTERVAL would be a welcome addition,
> could it be added as a TODO item? I would like to work on it, since I
> want to use some features that are not currently supported.
...
> Valid SQL92 syntax that is not currently supported:
...
> junk=# SELECT INTERVAL '1
Zeugswetter Andreas SB SD wrote:
>
> > > > >For bytea, follow this rule: to escape a null character, use
> this:
> > > > >'\\0'. To escape a backslash, use this: ''.
>
> Can anybody explain in technical terms why this is implemented
> so inconveniently ?
I think that this has to to with mak
Florian Weimer <[EMAIL PROTECTED]> writes:
> We therefore suggest that a string escaping function is included in a
> future version of PostgreSQL and libpq. A sample implementation is
> provided below, along with documentation.
We have now released a description of the problems which occur when
Stephan Szabo wrote:
>
> When you drop and recreate the table, you'll need to drop and recreate the
> rules that reference it as well. There's been little to no concensus as to
> what the correct behavior should be in such cases: delete the rules when
> a referenced table is removed, refuse to re
> > > >For bytea, follow this rule: to escape a null character, use
this:
> > > >'\\0'. To escape a backslash, use this: ''.
Can anybody explain in technical terms why this is implemented
so inconveniently ?
Since bytea is probably not very common among users yet
we could imho still change
26 matches
Mail list logo
