Re: Row level security policy

Thank you for clarifying this. I missed that even though it is there in the second paragraph. - Mark, out and about. > On Nov 14, 2024, at 1:57 AM, Laurenz Albe wrote: > > On Wed, 2024-11-13 at 17:33 -0800, Mark Phillips wrote: >> Given a database table with one policy state

Re: Row level security policy

FOR SELECT then additional policies are needed for insert, update and delete. > On Nov 13, 2024, at 6:13 PM, Mark Phillips wrote: > > Thank you. I will revisit my test cases to be sure I have the use cases > covered. > - Mark, out and about. > >> On Nov 13, 2

Re: Row level security policy

Thank you. I will revisit my test cases to be sure I have the use cases covered. - Mark, out and about.On Nov 13, 2024, at 5:36 PM, David G. Johnston wrote:On Wednesday, November 13, 2024, Mark Phillips <mphill...@mophilly.com> wrote:Given a database table with one policy statement FOR

Row level security policy

Given a database table with one policy statement FOR SELECT applied, it is necessary to apply additional policy statements for insert, update, and delete operations? My testing indicates that this is case but I haven’t found an explanation of this requirement in the documentation. - Mark

Re: create policy statement USING clause

e wrote: > > On Mon, 2024-11-11 at 15:10 -0800, Mark Phillips wrote: >> PostgreSQL 12 > > Upgrade now! > >> Given a table “customer” with a column “deadfiled” of the type boolean. The >> column >> deadfiled is used to indicate that a row is “in the trash b

create policy statement USING clause

PostgreSQL 12 Given a table “customer” with a column “deadfiled” of the type boolean. The column deadfiled is used to indicate that a row is “in the trash bin”. The app has a window that lists the contents of the “trash bin”, which any rows with deadfiled = true. Row so marked should be excluded

FTS and tri-grams

thoughts, experiences or other thoughts greatly appreciated. - Mark Phillips

limit of data type character varying

other hand, one could argue that a higher limit in postgres is sensible these days. Additional Information 1. symmetricds version 3.12.4 2. Postgresql Version 12 3. OS's Windows 10, Mac Catalina and SME Server Regards, Mark Phillips Mophilly Technology Inc. Telephone: (619) 296-0114 On th

Re: serial + db key, or guid?

Thanks to everyone who replied. All helpful. I learned and have new ideas to work with. > On Aug 11, 2020, at 10:42 AM, Adam Brusselback > wrote: > > I mentioned this in another email thread yesterday about a similar topic, but > I'd highly suggest if you do go the UUID route, do not use the

Re: serial + db key, or guid?

Thank you for the reply. The article is a good one. I posed the question on the chance things had evolved since 2012, specifically as it relates to postgres. > On Aug 10, 2020, at 3:21 PM, Christophe Pettus wrote: > > > >> On Aug 10, 2020, at 15:19, Mark Phillips

serial + db key, or guid?

Given four instances of posgres, each with a database, each instance receiving new data, and desiring a data “merge” a la BDR or similar multiple database solutions, my team has been discussing the pros and cons of generating unique keys in each table. 1. create a unique “database” id for each