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

Marc Munro <marc@bloodnok.com> 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

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

On Thu, 2008-06-12 at 19:10 -0400, Tom Lane wrote:

Marc Munro <marc@bloodnok.com> 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

Marc Munro <marc@bloodnok.com> 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