Magnus Hagander wrote: > Tom Lane wrote: >> Magnus Hagander <[EMAIL PROTECTED]> writes: >>> On Mon, Oct 01, 2007 at 10:51:01AM -0400, Tom Lane wrote: >>>> I'd vote for backpatching, but only as far as 8.2, seeing that we're >>>> abandoning the older branches on Windows. >>> Should we backpatch a version of it to previous versions that does just the >>> error stack manipulation, or just ignore on the grounds that nobody has >>> reported the problem there (it's there, but it's a lot more narrow - I know >>> it's there, but I havent' been able to provoket it due to not knowing >>> enough about setting up certificate chains and such) >> That's only a cosmetic problem (wrong error message), right? I'd vote >> for no backpatch, at least for now --- I'd rather see this change get >> through beta testing first. Anytime you're fooling with interactions >> with some other package, the risk of portability issues is high. > > Right. > Applied to HEAD. Will wait for a buildfarm cycle to make sure it doesn't > kill anything else then try to backport to 8.2 (patch didn't apply > cleanly to it)
I guess you guys already found a solution that works, but there's yet another function, "BIO *BIO_new_mem_buf(void *data, int len)", that we could use. We could open and read the file all by ourselves into memory, then call BIO_new_mem_buf and pass that to PEM_read_X509. No need to pass around file pointers, and we could handle any file I/O errors ourselves. Presumably certificates are never very big, so reading it all in memory shouldn't be a problem. BIO_new_mem_buf was introduced in OpenSSL 0.9.7. What versions do we support? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match