As Kris Jurka found out, pgcrypto does not work with
OpenSSL 0.9.6x. The DES functions use the older 'des_'
API, but the newer 3DES functions use the 0.9.7x-only
'DES_' API.
I think I just used /usr/include/openssl/des.h for reference
when implementing them, and had upgraded OpenSSL in the
meanti
On Thu, Jul 07, 2005 at 12:25:53PM +0300, Marko Kreen wrote:
>
> Tested with OpenSSL 0.9.6c and 0.9.7e.
I just applied this patch to my system running HEAD and OpenSSL 0.9.8;
all regression tests passed.
BTW, OpenSSL 0.9.8 has been released:
http://www.mail-archive.com/openssl-announce@openssl.
Koichi Suzuki <[EMAIL PROTECTED]> writes:
> Here're a couple of patches for PostgreSQL 64bit support. There're just
> two extension to 64bit, size of shared memory and transaction ID.
I asked originally for some experimental evidence showing any value
in having more than 2Gb of shared buffers. I
Tom Lane wrote:
Koichi Suzuki <[EMAIL PROTECTED]> writes:
Here're a couple of patches for PostgreSQL 64bit support. There're just
two extension to 64bit, size of shared memory and transaction ID.
I asked originally for some experimental evidence showing any value
in having more than 2Gb of
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> There is some practical evidence. Recently the number of large boxes in
> the field is almost growing exponentially. Today I have heard somebody
> say "this box has 'just 4 gig of ram' ".
> On large installations we have alrea
On Tue, Jul 05, 2005 at 03:51:32PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > On Tue, Jul 05, 2005 at 02:47:15PM -0400, Tom Lane wrote:
> >> Although I don't have any particular objection to the OWNER/NORMAL
> >> distinction, your explanation doesn't seem to make sense.
Tom Lane wrote:
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
There is some practical evidence. Recently the number of large boxes in
the field is almost growing exponentially. Today I have heard somebody
say "this box has 'just 4 gig of ram' ".
On large installations we
On Thu, Jul 07, 2005 at 06:23:40PM +0200, Hans-Jürgen Schönig wrote:
> Tom Lane wrote:
> >Koichi Suzuki <[EMAIL PROTECTED]> writes:
> >
> >>Here're a couple of patches for PostgreSQL 64bit support. There're just
> >>two extension to 64bit, size of shared memory and transaction ID.
> >
> >
> >I ask
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Tue, Jul 05, 2005 at 03:51:32PM -0400, Tom Lane wrote:
> An important distinction to be made is which dependencies are "auto" and
> which ones are "normal". It's clear that OWNER entries cannot be AUTO.
> OTOH grantee entries in the ACL can be (have
I have some experimeltal data about this extension. I will gather it
and post hopefully this weekend.
Tom Lane wrote:
> Koichi Suzuki <[EMAIL PROTECTED]> writes:
>
>>Here're a couple of patches for PostgreSQL 64bit support. There're just
>>two extension to 64bit, size of shared memory and tran
Hans-J|rgen Schvnig <[EMAIL PROTECTED]> wrote:
> 64-bit XIDs seem to be an overkill - the only practical impact I can see
> is an even larger tuple header (this can be an issue on large boxes too
> - at least compared to Oracle).
I agreed, too. The changes of XIDs cannot be ignored because
On Fri, Jul 08, 2005 at 09:38:07AM +0900, ITAGAKI Takahiro wrote:
> Hans-J|rgen Schvnig <[EMAIL PROTECTED]> wrote:
>
> > 64-bit XIDs seem to be an overkill - the only practical impact I can see
> > is an even larger tuple header (this can be an issue on large boxes too
> > - at least compare
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Fri, Jul 08, 2005 at 09:38:07AM +0900, ITAGAKI Takahiro wrote:
>> Avoiding overheads, can XIDs/CIDs be different bit length? For example,
>> can XIDs/CIDs be changed to 48/16-bit or 40/24-bit?
> Not unless you change the definition of HeapTupleFields
Neil Conway wrote:
> Tom Lane wrote:
>> I think this is all irrelevant language-lawyering; jtv spotted the true
>> problem which is that we do not protect errno during the *first* call of
>> libpq_gettext.
>
> I think you're missing the point. Obviously the current code is wrong,
> the debate is ov
Gavin Sherry wrote:
This patch removes dead code from redo_dbase(). The code processes
CREATE/DROP DATABASE recovery records which are of types
XLOG_DBASE_CREATE_OLD and XLOG_DBASE_DROP_OLD. We do not create such
records.
Applied with additional fixes (you forgot to remove the reference to the
Michael Fuhr wrote:
This patch updates the DDL for contrib/pgcrypto to create all
functions as STRICT, and all functions except gen_salt() as IMMUTABLE.
gen_salt() is VOLATILE.
Applied, thanks.
-Neil
---(end of broadcast)---
TIP 9: In versions b
Neil Conway wrote:
Ah, I see. I would be content to allow opt_sqlstate to be either a
string literal, a T_WORD (predefined error condition), or a TEXT
variable. If users need to throw a sqlstate that is derived from a SQL
expression, they can always assign to a TEXT variable and then specify
t
On Fri, 8 Jul 2005, Neil Conway wrote:
> Neil Conway wrote:
> > Ah, I see. I would be content to allow opt_sqlstate to be either a
> > string literal, a T_WORD (predefined error condition), or a TEXT
> > variable. If users need to throw a sqlstate that is derived from a SQL
> > expression, they
Neil Conway <[EMAIL PROTECTED]> writes:
> BTW, do have we reached a consensus on this?
Doesn't look that way --- I tend to agree with you that we could avoid
inventing declared exceptions at all, but Pavel is definitely not happy
with it, and AFAIR no one else has weighed in. Maybe we need to tak
Pavel Stehule wrote:
ok, but don't forget, please, on exception part.
What do you mean?
-Neil
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so th
On Fri, 8 Jul 2005, Neil Conway wrote:
> Pavel Stehule wrote:
> > ok, but don't forget, please, on exception part.
>
> What do you mean?
>
> -Neil
>
BEGIN
EXCEPTION WHEN * THEN
equvalent rules for raise have to be in *
is true?
Pavel
---(end of broadcast)--
On Fri, 8 Jul 2005, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > BTW, do have we reached a consensus on this?
>
> Doesn't look that way --- I tend to agree with you that we could avoid
> inventing declared exceptions at all, but Pavel is definitely not happy
> with it, and AFAIR
Per EDB's Coverity analysis, "runtimeKeyInfo" is only non-NULL if
"econtext" is also non-NULL, so we can eliminate a conditional on the
former by moving it inside an "if" block for the latter. Per discussion
of earlier similar changes, this is not for performance reasons but for
code clarity.
Neil Conway <[EMAIL PROTECTED]> writes:
> Per EDB's Coverity analysis, "runtimeKeyInfo" is only non-NULL if
> "econtext" is also non-NULL, so we can eliminate a conditional on the
> former by moving it inside an "if" block for the latter.
This is premature optimization par excellance --- it save
Tom Lane wrote:
>
> (1) The fact that gettext works at all seems to me to be sufficient
> empirical evidence that it's a working solution.
Tom, you have GOT to be joking. I agree with some of the things you say
(see below), but here you're just not making sense. Consider:
1. We're only talking
Pavel Stehule wrote:
BEGIN
EXCEPTION WHEN * THEN
equvalent rules for raise have to be in *
is true?
I'm sorry, but I'm still not sure what you mean.
-Neil
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your
26 matches
Mail list logo
