Make hba available to client code

David Fetter <david@fetter.org> writes:

While investigating another project, namely adding pg_hba.conf support
to pgbouncer, I ran into a stumbling block others probably will, too:
the hba code is backend-only, which means that if I were to do this
as-is, I would be cooking a batch of very unappetizing copypasta.

I'm allergic to copypasta, so unless there are big objections, I'd
like to export those functions to make hba available to other code.

How exactly would exporting those functions help anything client-side?

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

On Wed, Jan 28, 2015 at 04:10:42PM -0500, Tom Lane wrote:

David Fetter <david@fetter.org> writes:

While investigating another project, namely adding pg_hba.conf support
to pgbouncer, I ran into a stumbling block others probably will, too:
the hba code is backend-only, which means that if I were to do this
as-is, I would be cooking a batch of very unappetizing copypasta.

I'm allergic to copypasta, so unless there are big objections, I'd
like to export those functions to make hba available to other code.

How exactly would exporting those functions help anything client-side?

Right now, pgbouncer, and aspirational things like it--other
connection poolers, maybe distributed transaction managers, etc.--can
fairly easily act almost like a direct connection to PostgreSQL,
except for some important exceptions. One that's cropped up several
times is the ability to gate auth by network and user, that being what
pg_hba.conf allows.

A conversation with Andrew Dunstan since I posted convinced me that
the amount of work to separate this cleanly and have it perform
somewhere in the close range of as well as it does now could be pretty
significant.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 01/28/2015 04:26 PM, David Fetter wrote:

On Wed, Jan 28, 2015 at 04:10:42PM -0500, Tom Lane wrote:

David Fetter <david@fetter.org> writes:

While investigating another project, namely adding pg_hba.conf support
to pgbouncer, I ran into a stumbling block others probably will, too:
the hba code is backend-only, which means that if I were to do this
as-is, I would be cooking a batch of very unappetizing copypasta.
I'm allergic to copypasta, so unless there are big objections, I'd
like to export those functions to make hba available to other code.

How exactly would exporting those functions help anything client-side?

Right now, pgbouncer, and aspirational things like it--other
connection poolers, maybe distributed transaction managers, etc.--can
fairly easily act almost like a direct connection to PostgreSQL,
except for some important exceptions. One that's cropped up several
times is the ability to gate auth by network and user, that being what
pg_hba.conf allows.

A conversation with Andrew Dunstan since I posted convinced me that
the amount of work to separate this cleanly and have it perform
somewhere in the close range of as well as it does now could be pretty
significant.

I should add that I am working on an hba facility for pgbouncer. It's
currently in trial. I did pull in a few pieces of the core hba code, but
not a great deal - mainly to do with handling IP addresses and masks.

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

David Fetter <david@fetter.org> writes:

On Wed, Jan 28, 2015 at 04:10:42PM -0500, Tom Lane wrote:

How exactly would exporting those functions help anything client-side?

Right now, pgbouncer, and aspirational things like it--other
connection poolers, maybe distributed transaction managers, etc.--can
fairly easily act almost like a direct connection to PostgreSQL,
except for some important exceptions. One that's cropped up several
times is the ability to gate auth by network and user, that being what
pg_hba.conf allows.

A conversation with Andrew Dunstan since I posted convinced me that
the amount of work to separate this cleanly and have it perform
somewhere in the close range of as well as it does now could be pretty
significant.

I'm not sure I understand what you mean by "separate this cleanly",
but if what you mean is "rewrite hba.c so that it works either in
frontend or backend", I don't think I'm going to like the result;
and I'm not convinced that client-side code would find it all that
useful either. The API, error handling, and memory management would
probably all need to be a great deal different on client side. And
serving two masters like that would result in an unreadable mess.

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