Hi Tom!
On Wed, 22 Feb 2023 at 14:16, Tom Lane wrote:
> If you're happy allowing the application to decide if the filters will
> be enforced, maybe just create some views embodying those filters, and
> query those views when you want restrictions?
>
Yeah, thanks very much for the suggestion. It
Hi Martin
On Wed, 22 Feb 2023 at 13:12, Martin L. Buchanan
wrote:
>
> Anyway, Tom if it is feasible to put each tenant into its own database on
> the same server instance, that is what I recommend.
>
It is not, unfortunately. For brevity I skipped over some details - the
"tenants" are possibly
Hi all
I'm currently researching different strategies for retrofitting some
multi-tenant functionality into our existing Postgres-backed application.
One of the options is using RLS policies to do row filtering. This is quite
attractive as I dread the maintenance and auditing burden of adding
filt
Hi all
We have generally been using timestamps without timezones in our system. As
both our app servers and db server were set to UTC it so far hasn't been an
issue. However, that may not always be the case, so we want to tighten
things up a bit. We are also needing to do things like get the parti
On 18 December 2017 at 18:43, Thomas Kellerer wrote:
> > All of the timestamps in our system represent an instant in time, not
> > a clock date/time, so timestamp with time zone is more appropriate.
> > All of the data that is currently on disk in timestamp columns was
> > inserted in a db sessio
Hi all
We have generally been using timestamps without timezones in our system. As
both our app servers and db server were set to UTC it so far hasn't been an
issue. However, that may not always be the case, so we want to tighten
things up a bit. We are also needing to do things like get the parti
