Hi All,
Wondering whether there is a way to get the row-level security policy name in
the error message when it's violated.
I am only getting a more generic error message like this.
ERROR: new row violates row-level security policy for table "table_name"
Thanks for your help.
Regards,
Louis Ti
> On 6 Mar 2023, at 01:18, Louis Tian wrote:
> Wondering whether there is a way to get the row-level security policy name in
> the error message when it's violated.
> I am only getting a more generic error message like this.
> ERROR: new row violates row-level security policy for table "table_
Hi. Perhaps I missed it in the doc (e.g. [1]), but are DDLs around ROLEs
and GRANTs transactional?
Since I'm creating many ROLEs and making many GRANTs, based info I read
from PostgreSQL itself (in pg_catalog and elsewhere), should everything be
in a single transaction?
FWIW, I come from Oracle (
> On 06/03/2023 14:19 CET Dominique Devienne wrote:
>
> Perhaps I missed it in the doc (e.g. [1]), but are DDLs around ROLEs and
> GRANTs transactional?
Have you tried? DDL is transactional unless stated otherwise (cf. CREATE
DATABASE,
CREATE INDEX CONCURRENTLY, CREATE TABLESPACE).
Run the fol
Dominique Devienne writes:
> Hi. Perhaps I missed it in the doc (e.g. [1]), but are DDLs around ROLEs
> and GRANTs transactional?
Your expectation is set wrongly. DDL commands in Postgres are
transactional unless their man page explicitly says they're not.
regards, tom l
On Mon, Mar 6, 2023 at 4:06 PM Tom Lane wrote:
> Dominique Devienne writes:
> > Hi. Perhaps I missed it in the doc (e.g. [1]), but are DDLs around ROLEs
> > and GRANTs transactional?
>
> Your expectation is set wrongly.
Thanks for the precision Tom.
Although I'm not sure where you read my exp
Dominique Devienne writes:
> On Mon, Mar 6, 2023 at 4:06 PM Tom Lane wrote:
>> DDL commands in Postgres are
>> transactional unless their man page explicitly says they're not.
> Could you point to where in the doc this is stated?
For example, for CREATE DATABASE the first "Note" para in [1] is
On Mon, Mar 6, 2023 at 3:02 PM Erik Wienhold wrote:
> > On 06/03/2023 14:19 CET Dominique Devienne wrote:
> > Perhaps I missed it in the doc (e.g. [1]), but are DDLs around ROLEs and
> > GRANTs transactional?
>
> Have you tried?
Nope. I thought about it, but then I could have convinced myself
On Mon, Mar 6, 2023 at 4:31 PM Tom Lane wrote:
> Dominique Devienne writes:
> > On Mon, Mar 6, 2023 at 4:06 PM Tom Lane wrote:
> >> DDL commands in Postgres are
> >> transactional unless their man page explicitly says they're not.
>
> > Could you point to where in the doc this is stated?
>
> Fo
I was doing a SELECT * FROM view WHERE field LIKE pattern
and getting garbage data back.
Turns out it is filtering on a different field.
As you can see here, when attempting to filter on the FileKey, it is
actually filtering on the Order Item ID field.
select "FileKey", "OrderItemID" from "vw_rp
On 3/6/23 12:17, Brad White wrote:
I was doing a SELECT * FROM view WHERE field LIKE pattern
and getting garbage data back.
Turns out it is filtering on a different field.
As you can see here, when attempting to filter on the FileKey, it is
actually filtering on the Order Item ID field.
sele
On Mon, Mar 6, 2023 at 1:18 PM Brad White wrote:
>
> As you can see here, when attempting to filter on the FileKey, it is
> actually filtering on the Order Item ID field.
>
> select "FileKey", "OrderItemID" from "vw_rptInvc_Permits"
> where "FileKey" LIKE '%1317'
>
> I'm stumped. Any guesses?
>
LOL
Joke's on me.
Here's the relevant part of the view
SELECT ...
"Order Items"."ID" AS "OrderItemID",
...
(("Orders"."ID" || '-'::text) || "Order Items"."ID") AS "FileKey"
Wait, then why are the Item IDs different?
Here are the results again, with the FileKey field expanded a bit.
On Mon, Mar 6, 2023 at 1:48 PM Brad White wrote:
> LOL
>
> Joke's on me.
>
> Here's the relevant part of the view
>
> SELECT ...
> "Order Items"."ID" AS "OrderItemID",
> ...
> (("Orders"."ID" || '-'::text) || "Order Items"."ID") AS "FileKey"
>
> Wait, then why are the Item IDs differe
On 3/6/23 12:48 PM, Brad White wrote:
LOL
Joke's on me.
Here's the relevant part of the view
SELECT ...
"Order Items"."ID" AS "OrderItemID",
...
(("Orders"."ID" || '-'::text) || "Order Items"."ID") AS "FileKey"\
Because "Orders"."ID" is different then "Order Items"."ID"?
W
In that picture, it's clear what is happening.
Here, again, is the result that had me stumped.
[image: image.png]
What threw me was that the field I was looking for had the format of 6d-4d
and this field appeared to have the same format.
But once you expand it, you can see that it has a 6d-7d forma
On 3/6/23 1:27 PM, Brad White wrote:
In that picture, it's clear what is happening.
Here, again, is the result that had me stumped.
image.png
What threw me was that the field I was looking for had the format of
6d-4d and this field appeared to have the same format.
But once you expand it, you ca
I have an idea/request for enhancement to PostgreSQL (I'm new to PostgreSQL
and this mailing list).
Idea:
There's a technique in Oracle SQL that can be used to simplify aggregation
queries:
*Aggregate on a particular column, but get information from
Ben Clements writes:
> As shown above, the following calculated column can bring in the city name,
> even though the city name isn't in the GROUP BY:
>max(city) keep (dense_rank first order by population desc)
You haven't really explained what this does, let alone why it can't
be implemented
I am trying to sharpen my understanding of Postgres. As I understand,
Postgres does not write directly to disk blocks. It uses the file system
provided by the OS:
https://dba.stackexchange.com/questions/80036/is-there-a-way-to-store-a-postgresql-database-directly-on-a-block-device-not-fi
My questio
On 3/6/23 18:24, Siddharth Jain wrote:
I am trying to sharpen my understanding of Postgres. As I understand,
Postgres does not write directly to disk blocks. It uses the file system
provided by the OS:
https://dba.stackexchange.com/questions/80036/is-there-a-way-to-store-a-postgresql-database-d
> On Mar 6, 2023, at 16:24, Siddharth Jain wrote:
> My question: How can it then store a B Tree on disk? I would think storing a
> B Tree requires storing disk offset addresses and so on (for a node to
> navigate to another etc.). For this, one would need to write directly to the
> disk usin
On Tue, 7 Mar 2023 at 12:40, Tom Lane wrote:
>
> Ben Clements writes:
> > As shown above, the following calculated column can bring in the city name,
> > even though the city name isn't in the GROUP BY:
> >max(city) keep (dense_rank first order by population desc)
>
> You haven't really expla
thanks Christophe. will try to go through it. its bit difficult to grasp.
On Mon, Mar 6, 2023 at 5:08 PM Christophe Pettus wrote:
>
>
> > On Mar 6, 2023, at 16:24, Siddharth Jain wrote:
> > My question: How can it then store a B Tree on disk? I would think
> storing a B Tree requires storing di
On Mon, Mar 6, 2023 at 7:51 PM David Rowley wrote:
> On Tue, 7 Mar 2023 at 12:40, Tom Lane wrote:
> >
> > Ben Clements writes:
> > > As shown above, the following calculated column can bring in the city
> name,
> > > even though the city name isn't in the GROUP BY:
> > >max(city) keep (dens
On Tue, 7 Mar 2023 at 16:11, David G. Johnston
wrote:
>
> On Mon, Mar 6, 2023 at 7:51 PM David Rowley wrote:
>> the transfn for bottom() would need to remember the city and the
>> population for the highest yet seen value of the 2nd arg.
>
>
> BOTTOM() remembers the highest value?
I was thinking
Hi,
We are facing following issue with postgres db with Kubernetes. Is huge pages
not supported in Kubernetes environment?
Multiple core dump errors are thrown by initdb when Huge pages are enabled in
OS and huge_pages is set to “off” in postgresql.conf.sample in Kubernetes.
In this case, the in
Hi,
On Tue, Mar 07, 2023 at 05:44:53AM +, M Tarkeshwar Rao wrote:
>
> We are facing following issue with postgres db with Kubernetes. Is huge pages
> not supported in Kubernetes environment?
> Multiple core dump errors are thrown by initdb when Huge pages are enabled in
> OS and huge_pages is
28 matches
Mail list logo
