* Andrew Dunstan (and...@dunslane.net) wrote: > Or we try to make it work. I don't think the idea is inherently bad, > and I know there are people (like ISPs) who would like to have it > work properly. Maybe in these days when most people are on dedicated > VMs this matters less, but I don't think shared database servers are > totally dead yet.
Agreed. There are certainly pretty big hosting companies out there
which are already doing multi-tenant PG, but they're using their own
approaches instead of anything we provide (because what we provide
sucks, basically..).
> The docs say:
>
> db_user_namespace causes the client's and server's user name
> representation to differ. Authentication checks are always done with
> the server's user name so authentication methods must be configured
> for the server's user name, not the client's. Because md5 uses the
> user name as salt on both the client and server, md5 cannot be used
> with db_user_namespace.
>
> Is that the only major issue? Why not have the server strip out the
> @db part if this is on? If we made this an initdb-time setting
> rather than a GUC then we'd remove the problems caused by turning
> this on and off. I'm not sure what other problems that might cause,
> but it doesn't seem totally intractable at first glance.
Isn't the other issue for ISPs essentially that we don't have row-level
security for our global catalogs? as in- we can't limit what's in
pg_authid to only those entries a given user should be able to see? I
don't think db_user_namespace addresses that issue (but I didn't go look
either).
Thanks,
Stephen
signature.asc
Description: Digital signature
