Mike Mascari <mascarm@mascari.com> writes:
> On the general list a while back someone wanted to implement
> a view where the records visible to the client were
> dependent upon an application defined user id. I, too, am in
> a similar circumstance. However, one solution would be to do
> something like this:
> SELECT authenticate(<userid>, <password>);
> where <userid> and <password> are submitted by the client
> application as input from the user.
This seems like a completely redundant mechanism to me.
What is wrong with using the *existing* user authentication
mechanisms, and then using getpgusername() or CURRENT_USER
in your queries?
> At any rate. the whole point of this deal is that anyone
> wanting to write a 'C' function which needs to access tuples
> has to use the SPI interface. And at the moment, that means
> they need the source tree to the backend.
I can't really see anyone writing SPI functions without access to
a source tree; there's too much stuff that's most readily learned
by looking at the code. But I think you are right that the installed
include tree is probably insufficient to *compile* the average SPI
function, and that's not good. We haven't been paying much attention
to the question of which headers need to be installed. There are
probably some installed that needn't be anymore, as well as vice versa.
Proposed TODO:
* Re-examine list of header files that get installed, add/delete as needed
regards, tom lane