Emmanuel Charpentier <[EMAIL PROTECTED]> writes:
> However, this does *not* work between a 7.3-generated dump and a 7.2
> production server. The archiver complaints of an 'unknown archive format :
> "0"' (I'm quoting this from the top of my head : my production server is
> not reachable from the pl
- Original Message -
From: "Gavin Sherry" <[EMAIL PROTECTED]>
[snip]
> > Where is the "other" flush besides FlushFileBuffers()?
>
> The only real code there is, it seems, an exclusive look on the file
> descriptor. (Provided of course that that is what _lock_fh(filedes) does).
>
yes, it l
On Mon, Feb 03, 2003 at 22:55:12 -0600,
Greg Copeland <[EMAIL PROTECTED]> wrote:
>
> I'll say this again. Checksums alone offers zero security protection.
> It was never intended to address that purpose. As such, it does not
> address it. If you need security, use a security product. Checks
I think the fopen or _open family of functions all map directly to the
win32 API. They add a little cruft, which generally makes using them
pointless, because you have less control over security, caching, and
other such things when opening the file. There is the slight overhead
of the extra call,
I have been in communication with O'Reilly, and they are hoping for
another strong PostgreSQL showing at the O'Reilly convention this year.
We have until February 15th to submit tutorials (3 hours) and
presentations (45 or 90 minutes).
If you are interested, please go to:
http://conferen
Hello!
I have dropped some columns and have quite some problems now with RECTYPE
variables types.
My question: Can I RECREATE dropped columns?
I checked the pg_attribute table and there I can change values of attname,
attstattarget and attisdropped
for my column. Will this work? Is there any sid
OK,
I redid my trials with the same data set on 7.2.3 --with-multibyte and I
get the same brutal performance hit, so it is definitely a
multibyte-specific problem.
WRT the distribution of the data in the table, I used the following:
All g-words in /usr/share/dict with different processes attac
wade <[EMAIL PROTECTED]> writes:
> I redid my trials with the same data set on 7.2.3 --with-multibyte and I
> get the same brutal performance hit, so it is definitely a
> multibyte-specific problem.
>
> There are only about 1000 words that appear more than once (2 or 3 times)
> in 27k rows.
Righ
On Tue, 2003-02-04 at 11:24, wade wrote:
> I redid my trials with the same data set on 7.2.3 --with-multibyte and I
> get the same brutal performance hit, so it is definitely a
> multibyte-specific problem.
Given that this problem isn't a regression, I don't think we need to
delay 7.3.2 to fix i
Neil Conway <[EMAIL PROTECTED]> writes:
> Given that this problem isn't a regression, I don't think we need to
> delay 7.3.2 to fix it (of course, a fix for 7.3.3 and 7.4 is essential,
> IMHO).
No, I've had to abandon my original thought that it was a localized bug,
so it's not going to be fixed i
"Damjan Pipan" <[EMAIL PROTECTED]> writes:
> I have dropped some columns and have quite some problems now with RECTYPE
> variables types.
> My question: Can I RECREATE dropped columns?
> I checked the pg_attribute table and there I can change values of attname,
> attstattarget and attisdropped
> fo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There are generally two ways to do it: have a "project" key, or have
each developer use their own key. The advantage of the first way is
that each release is signed by the same key, which is clearly
associated with the project. The disadvantage is
On Tue, 2003-02-04 at 11:59, Tom Lane wrote:
> I'm about to go off and look at whether we can absorb the Tcl regex
> package, which is Spencer's new baby. That will not be a solution for
> 7.3.anything, but it could be an answer for 7.4.
Sounds like we had about the same idea at about the same ti
Neil Conway <[EMAIL PROTECTED]> writes:
> Sounds like we had about the same idea at about the same time -- I
> emailed Henry Spencer inquiring about the new RE engine last night.
I just did that this morning ;-) ... but more as politeness than
anything else. AFAICT from searching the net, packagi
On Tue, 4 Feb 2003, Neil Conway wrote:
> Spencer's implementation is outperformed by some other RE engines,
> notably PCRE (www.pcre.org). But switching to another engine might
> impose backward-compatibility problems, in terms of the details of the
> RE syntax.
It would be a delight to be able t
On Tue, Feb 04, 2003 at 01:35:47PM +0900, Curt Sampson wrote:
> On Mon, 3 Feb 2003, Kurt Roeckx wrote:
>
> > I'm not saying md5 is as secure as pgp, not at all, but you can't
> > trust those pgp keys to be the real one either.
>
> Sure you can. Just verify that they've been signed by someone you
On Tue, 2003-02-04 at 12:55, Kurt Roeckx wrote:
> On Tue, Feb 04, 2003 at 01:35:47PM +0900, Curt Sampson wrote:
> > On Mon, 3 Feb 2003, Kurt Roeckx wrote:
> >
> > > I'm not saying md5 is as secure as pgp, not at all, but you can't
> > > trust those pgp keys to be the real one either.
> >
> > Sure
Having just started working with GPG I shouldn't be considered an expert but
it seems to me that each core developer should create a key and should
cross-sign each others' keys to form a web of trust to verify the
authenticity of those signatures. In any case, I think that if
security-related p
Can someone point me to an online doc to read through on this?
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Jon Jensen <[EMAIL PROTECTED]> writes:
> It would be a delight to be able to use more advanced (IMHO) Perl-
> compatible regexes in PostgreSQL.
After some further research, pcre does seem like an interesting
alternative. Both pcre and Spencer's new code have essentially
Berkeley-style licenses, s
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > It also clarifies the docs to mention it sits on the last row, not after
> > the last row.
>
> Is it true ?
Oops. I thought we didn't match the spec because we _didn't_ go past
the last row, but now I see it is because we do go past the last
When I first saw this thread I thought of the PHP docs which I recently started
using, from a level of knowing absolutely nothing of PHP.
Sure there was some useful stuff in some of the comments but some of the pages
were very long, far more comment than manual page. A lot of the comments refer
t
That was interesting. I love the TRS-80 mention. So, it seems your
logic is pretty much the same as ours --- trim them up and improve the
docs.
So, that particular URL was an example of what _not_ to do. I have
heard folks say they like the PHP comments a lot, but I wonder how much
of that is t
On Tue, 2003-02-04 at 16:59, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Given that this problem isn't a regression, I don't think we need to
> > delay 7.3.2 to fix it (of course, a fix for 7.3.3 and 7.4 is essential,
> > IMHO).
>
> No, I've had to abandon my original thought tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Can someone point me to an online doc to read through on this?
http://www.desktoplinux.com/articles/AT3341468184.html
http://www.gnupg.org/gph/en/manual.html
- --
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key: 0x14964AC8 200302041356
-BEGI
> > It would be a delight to be able to use more advanced (IMHO) Perl-
> > compatible regexes in PostgreSQL.
>
> After some further research, pcre does seem like an interesting
> alternative. Both pcre and Spencer's new code have essentially
> Berkeley-style licenses, so there's no problem there.
On Tue, 2003-02-04 at 13:21, Tom Lane wrote:
> After some further research, pcre does seem like an interesting
> alternative. Both pcre and Spencer's new code have essentially
> Berkeley-style licenses, so there's no problem there.
Keep in mind that pcre has an advertising clause in its license
(
Comments intermixed below.
On Tue, 2003-02-04 at 12:04, Steve Crawford wrote:
> Having just started working with GPG I shouldn't be considered an expert but
> it seems to me that each core developer should create a key and should
> cross-sign each others' keys to form a web of trust to verify th
On Tue, 2003-02-04 at 12:02, Rod Taylor wrote:
> On Tue, 2003-02-04 at 12:55, Kurt Roeckx wrote:
> > On Tue, Feb 04, 2003 at 01:35:47PM +0900, Curt Sampson wrote:
> > > On Mon, 3 Feb 2003, Kurt Roeckx wrote:
> > >
> > > > I'm not saying md5 is as secure as pgp, not at all, but you can't
> > > > tr
Tom Lane wrote:
Emmanuel Charpentier <[EMAIL PROTECTED]> writes:
However, this does *not* work between a 7.3-generated dump and a 7.2
production server. The archiver complaints of an 'unknown archive format :
"0"' (I'm quoting this from the top of my head : my production server is
not reachable
On Tue, Feb 04, 2003 at 02:04:01PM -0600, Greg Copeland wrote:
>
> Even improperly used, digital signatures should never be worse than
> simple checksums. Having said that, anyone that is trusting checksums
> as a form of authenticity validation is begging for trouble.
Should I point out that a
Proof of concept:
PG 7.3 using regression database:
regression=# select count(*) from tenk1 where 'quotidian' ~ string4;
count
---
0
(1 row)
Time: 676.14 ms
regression=# select count(*) from tenk1 where 'quotidian' ~ stringu1;
count
---
0
(1 row)
Time: 3426.96 ms
regression=
On Tue, 4 Feb 2003, Kurt Roeckx wrote:
> I know how it works, it's just very unlikely I'll ever meet
> someone so it gives me a good chain.
One postgresql conference is all it takes.
> Anyway, I think pgp is good thing to do, just don't assume that
> it's always better then just md5.
I think it
On Tue, 2003-02-04 at 17:26, Tom Lane wrote:
> Proof of concept:
> [...]
Very cool work, Tom.
> In the first case there are only four distinct patterns used, so we're
> running with cached precompiled regexes. In the other cases a new regex
> compilation must occur at each row.
Speaking of whic
On Tue, 4 Feb 2003, Kurt Roeckx wrote:
> > There really isn't any comparison here.
>
> I didn't say you could compare the security offered by both of
> them. All I said was that md5 also makes sense from a security
> point of view.
MD5, or any other unsigned check, makes sense from a security po
Neil Conway <[EMAIL PROTECTED]> writes:
> Speaking of which, is there (or should there be) some mechanism for
> increasing the size of the compiled pattern cache? Perhaps a GUC var?
I thought about that while I was messing with the code, but I don't
think there's much point in it, unless someone w
On Tue, 2003-02-04 at 16:13, Kurt Roeckx wrote:
> On Tue, Feb 04, 2003 at 02:04:01PM -0600, Greg Copeland wrote:
> >
> > Even improperly used, digital signatures should never be worse than
> > simple checksums. Having said that, anyone that is trusting checksums
> > as a form of authenticity vali
On Tue, 2003-02-04 at 16:13, Kurt Roeckx wrote:
> On Tue, Feb 04, 2003 at 02:04:01PM -0600, Greg Copeland wrote:
> >
> > Even improperly used, digital signatures should never be worse than
> > simple checksums. Having said that, anyone that is trusting checksums
> > as a form of authenticity valid
> "Damjan Pipan" <[EMAIL PROTECTED]> writes:
> > I have dropped some columns and have quite some problems now
> with RECTYPE
> > variables types.
> > My question: Can I RECREATE dropped columns?
> > I checked the pg_attribute table and there I can change values
> of attname,
> > attstattarget and a
- Original Message -
From: "Kurt Roeckx" <[EMAIL PROTECTED]>
>
> Should I point out that a "fingerprint" is nothing more than a
> hash?
>
If somebody shows you their passport to prove who they are and then gives
you a fingerprint of their PGP key, they have implicitly signed that
fingerpr
On Tue, 2003-02-04 at 17:15, Neil Conway wrote:
> On Tue, 2003-02-04 at 11:59, Tom Lane wrote:
> > I'm about to go off and look at whether we can absorb the Tcl regex
> > package, which is Spencer's new baby. That will not be a solution for
> > 7.3.anything, but it could be an answer for 7.4.
>
>
Ok. The original complain can be sasily solved at least for single
byte encoding databases. With the small patches(against 7.3.1)
included, I got following result.
test1:
select count(*) from tenk1 where 'quotidian' ~ string4;
count
---
0
(1 row)
Time: 113.81 ms
test2:
select count(*)
On Tue, Feb 04, 2003 at 23:13:47 +0100,
Kurt Roeckx <[EMAIL PROTECTED]> wrote:
>
> So a figerprint and all the hash/digest function have no purpose
> at all?
The purpose of both is to reduce the amount of material in a way that
makes it hard to generate some other material that would result in
On Tue, 2003-02-04 at 18:21, Tom Lane wrote:
> 4. pcre looks like it's probably *not* as well suited to a multibyte
> environment. In particular, I doubt that its UTF8 compile option was
> even turned on for the performance comparison Neil cited --- and the man
> page only promises "experimental,
Hannu Krosing <[EMAIL PROTECTED]> writes:
> If we are going into code-lifting business, we should also consider
> Pythons sre
What advantages does it have to make it worth considering?
regards, tom lane
---(end of broadcast)
Tom Lane kirjutas T, 04.02.2003 kell 21:18:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > If we are going into code-lifting business, we should also consider
> > Pythons sre
>
> What advantages does it have to make it worth considering?
Should be the same as pcre + support for wide chars.
--
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Tom Lane kirjutas T, 04.02.2003 kell 21:18:
>> What advantages does it have to make it worth considering?
> Should be the same as pcre + support for wide chars.
Well, if someone wants to do the legwork to try it, that interface
should work just about co
Tom Lane kirjutas K, 05.02.2003 kell 01:35:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Speaking of which, is there (or should there be) some mechanism for
> > increasing the size of the compiled pattern cache? Perhaps a GUC var?
>
> I thought about that while I was messing with the code, but I
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Another idea is to make special regex type and store the regexes
> pre-parsed (i.e. in some fast-load form) ?
Seems unlikely that going out to disk could beat just recompiling the
regexp. They're not *that* slow to compile ... at least not when we
avoid
49 matches
Mail list logo
