Re: SSL certificate info on SQL level and HSM support for libpq

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: "Victor B(dot) Wagner" <vitus(at)cryptocom(dot)ru>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SSL certificate info on SQL level and HSM support for libpq
Date: 2006-05-19 08:02:34
Message-ID: 20060519080234.GC17873@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 19, 2006 at 10:33:52AM +0400, Victor B. Wagner wrote:
> 1. Am I correct that these function have to be INTERNAL? Or it is
> possible to get access to MyProcPort variable (on Windows platform too)
> from dynamically loadable object?

You should be able to have these in a contrib module, Postgres exports
all symbols.

> 2. I can make OpenSSL to return UTF-8 string for certificate name
> fields. How to convert them into current database encoding. Where to
> look up information of PostgreSQL backend encoding conversion functions
> and how to determine database encoding from C function short of
> connecting to SPI manager and issue SQL query?

Look up the docs for encodings, but there are functions to convert
strings.

> 3. Almost same question about arbitrary precession integer values.
> Where to look up C functions to convert decimal/hexadecimal/binary
> string representing integer of 128 bits or so into Postgres NUMERIC
> type.

numeric_in converts a text string to a numeric. Don't know about 128
bit strings though.

> 4. Is it good idea to use (ANSI standard) VARCHAR arguments or return
> values? I see that PostgreSQL specific TEXT type is used more often by
> internal PostgreSQL functions.

TEXT is VARCHAR minus the length check.

> 5. Is there some coding-style guidelines? I'm planning to submit this
> patch to pgsql-patches next week, and I want to make it as easily
> acceptable as possible.

There is a coding style somewhere, I think... Have you read the
developers FAQ?

--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tommi Maekitalo 2006-05-19 08:37:26 Re: [OT] MySQL is bad, but THIS bad?
Previous Message Jeroen T. Vermeulen 2006-05-19 07:55:53 Re: [OT] MySQL is bad, but THIS bad?