FAQ
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

Search Discussions

  • Andrew Dunstan at Jun 12, 2008 at 11:07 pm

    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 at Jun 12, 2008 at 11:30 pm

    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
  • Tom Lane at Jun 12, 2008 at 11:11 pm

    Marc Munro 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
  • Marc Munro at Jun 12, 2008 at 11:32 pm

    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
  • Tom Lane at Jun 12, 2008 at 11:42 pm

    Marc Munro 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJun 12, '08 at 10:02p
activeJun 12, '08 at 11:42p
posts6
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase