Re: [HACKERS] b64_encode and decode
Marc Munro <[EMAIL PROTECTED]> writes: > On Thu, 2008-06-12 at 19:10 -0400, Tom Lane wrote: >> It'd only last until the next time Bruce runs his script that >> static-izes things that aren't used outside their own module ... > Hmmm. Does that script look in contrib? If so I'd be happy to provide > a patch to eliminate the redundancy there. Yeah, I believe so --- or at least, the problem would become obvious as soon as it hit the buildfarm. If you can get rid of the duplicative code in contrib/pgcrypto, then by all means patch away. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] b64_encode and decode
On Thu, 2008-06-12 at 19:10 -0400, Tom Lane wrote: > Marc Munro <[EMAIL PROTECTED]> writes: > > So, would there be any chance of redefining the base64 functions in > > encode.c as extern to eliminate this redundancy? > > It'd only last until the next time Bruce runs his script that > static-izes things that aren't used outside their own module ... Hmmm. Does that script look in contrib? If so I'd be happy to provide a patch to eliminate the redundancy there. If not, maybe it could be persuaded to be more inclusive? __ Marc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] b64_encode and decode
On Thu, 2008-06-12 at 19:07 -0400, Andrew Dunstan wrote: > Marc Munro wrote: > > I require base64 or some similar encoding scheme from a C language. . . > > > > I know I could call these functions indirectly by calling binary_ecncode > > through DirectFunctionCalln() but this is a whole lot more complexity > > and overhead than I'd like. . . > > > Just how much complexity do you think calling binary_encode involves? > You can probably do the whole thing in one or two lines of code. I'm sure that's true once I've got my head around the mechanism, but it adds two levels of indirection that seem quite unnecessary, and given that the author of pgcrypto has also wound up copying the functions I guess I'm not the only one who'd rather avoid it. If there are good reasons not to expose the functions, or if the hackers just don't want to do it I'm fine with that. For dealing with 8.3 and earlier I will have to live with the redundancy. For 8.4 I'd like not to, but it's really not a big deal. Thanks for the response though. Being able to get a response from developers means a lot. I used to be an Oracle DBA and I have to say the response I get from this group is light years ahead of what I used to have to pay for. __ Marc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] b64_encode and decode
Marc Munro <[EMAIL PROTECTED]> writes: > So, would there be any chance of redefining the base64 functions in > encode.c as extern to eliminate this redundancy? It'd only last until the next time Bruce runs his script that static-izes things that aren't used outside their own module ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] b64_encode and decode
Marc Munro wrote: I require base64 or some similar encoding scheme from a C language extension and need it to be as fast as reasonably possible. In src/backend/utils/adt/encode.c there are functions b64_encode and b64_decode which would be ideal but these are defined static and so are not available to my code. I know I could call these functions indirectly by calling binary_ecncode through DirectFunctionCalln() but this is a whole lot more complexity and overhead than I'd like. I note that /contrib/pgcrypto/pgp-armor.c appears to have its own copies of these 2 functions and now I have elected to do the same. So, would there be any chance of redefining the base64 functions in encode.c as extern to eliminate this redundancy? Just how much complexity do you think calling binary_encode involves? You can probably do the whole thing in one or two lines of code. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] b64_encode and decode
I require base64 or some similar encoding scheme from a C language extension and need it to be as fast as reasonably possible. In src/backend/utils/adt/encode.c there are functions b64_encode and b64_decode which would be ideal but these are defined static and so are not available to my code. I know I could call these functions indirectly by calling binary_ecncode through DirectFunctionCalln() but this is a whole lot more complexity and overhead than I'd like. I note that /contrib/pgcrypto/pgp-armor.c appears to have its own copies of these 2 functions and now I have elected to do the same. So, would there be any chance of redefining the base64 functions in encode.c as extern to eliminate this redundancy? __ Marc signature.asc Description: This is a digitally signed message part