Hello Friends,
We are newly moving to postgres database (yet to decide if it would be an
on premise one or AWS aurora postgres). However , we want to understand
what encryption / decryption techniques are available in the postgres
database.
We may have some sensitive/"personal information" (lik
On Fri, 16 Feb 2024 at 06:04, Peter J. Holzer wrote:
> On 2024-02-15 16:51:56 -0700, David G. Johnston wrote:
> > On Thu, Feb 15, 2024 at 4:31 PM Peter J. Holzer
> wrote:
> > On 2024-02-14 22:55:01 -0700, David G. Johnston wrote:
> > > On Tuesday, February 13, 2024, veem v wrote:
> >
On 2024-02-15 16:51:56 -0700, David G. Johnston wrote:
> On Thu, Feb 15, 2024 at 4:31 PM Peter J. Holzer wrote:
> On 2024-02-14 22:55:01 -0700, David G. Johnston wrote:
> > On Tuesday, February 13, 2024, veem v wrote:
> >
> > float data types rather than numeric. This will giv
On 2024-02-15 23:51, Peter J. Holzer wrote:
On 2024-02-14 11:25:48 +0100, Daniel Gustafsson wrote: On 14 Feb 2024,
at 10:59, Simon Connah wrote:
This is probably a stupid question so I apologies in advance.
There is no such thing.
What I think is the best way to do this is to do a pg_dump of
On 2024-02-14 10:02:37 -0500, Greg Sabino Mullane wrote:
> "Fiscal year" double precision,
>
> This column is an INTEGER in your other table, so your schema is not even
> internally consistent! Try to use TEXT, INT, DATE and TIMESTAMPTZ whenever
> possible,
While using double precision fo
On Thu, Feb 15, 2024 at 4:31 PM Peter J. Holzer wrote:
> On 2024-02-14 22:55:01 -0700, David G. Johnston wrote:
> > On Tuesday, February 13, 2024, veem v wrote:
> >
> > float data types rather than numeric. This will give better
> performance.
> >
> >
> > Only use an inexact floating-point
On 2024-02-14 11:25:48 +0100, Daniel Gustafsson wrote:
> > On 14 Feb 2024, at 10:59, Simon Connah
> > wrote:
>
> > This is probably a stupid question so I apologies in advance.
>
> There is no such thing.
>
> > What I think is the best way to do this is to do a pg_dump of the
> > database (usi
On 2024-02-14 22:55:01 -0700, David G. Johnston wrote:
> On Tuesday, February 13, 2024, veem v wrote:
>
> float data types rather than numeric. This will give better performance.
>
>
> Only use an inexact floating-point data type if you truly understand what you
> are getting yourself into
I really worry you are overthinking this. The only real concern is going
from INT to BIGINT, jumping from 4 to 8 bytes or storage. That really
covers 99% of real world cases, and the canonical advice is to start with
BIGINT if you ever think your rows are going to be numbered in the
billions. Also,
On Thu, Feb 15, 2024 at 12:18 PM veem v wrote:
>
> So one learning for me, i.e. one of the downside of fixed length data type
> is, with fixed length data types any future changes to it , will be a full
> table rewrite. And thus this sort of change for big tables will be a
> nightmare.
>
>
Yes, u
On Thu, Feb 15, 2024 at 06:07:51PM +0100, Dominique Devienne wrote:
> When I read about v16, I thought great, this fits our intent, a single "owner"
> ROLE with CREATEROLE which is limited to administering only the ROLEs it
> created itself. I've always been bothered by the mega-power of CREATEROLE
On Thu, 15 Feb 2024 at 22:40, Adrian Klaver
wrote:
> On 2/15/24 09:00, Greg Sabino Mullane wrote:
> > On Thu, Feb 15, 2024 at 11:43 AM Adrian Klaver
> > mailto:adrian.kla...@aklaver.com>> wrote:
> >
> > That is a mixed bag:
> >
> >
> > Ha! Good point. Our contrived example table does suffer f
Hi,
On 15.02.2024 20:07, Dominique Devienne wrote:
And now with V16.1 ===
ddevienne=> create role zowner nologin createrole; -- owner of app's
schemas and manager of related roles
CREATE ROLE
ddevienne=> set role zowner;
ERROR: permission denied to set role "zowne
On 2/15/24 09:00, Greg Sabino Mullane wrote:
On Thu, Feb 15, 2024 at 11:43 AM Adrian Klaver
mailto:adrian.kla...@aklaver.com>> wrote:
That is a mixed bag:
Ha! Good point. Our contrived example table does suffer from that, so
perhaps the test should be:
create table int_test(c1 int, c2
Hi. Our "app" depends on many ROLEs and SCHEMAs, and manages GRANTs between
those.
Typically, each "instance" of our app lives in its own DB, and uses a
naming convention for its ROLEs, to make those role names unique
per-app-instance. All the app roles are created by a single master role
(the "own
On Thu, Feb 15, 2024 at 11:43 AM Adrian Klaver
wrote:
> That is a mixed bag:
>
Ha! Good point. Our contrived example table does suffer from that, so
perhaps the test should be:
create table int_test(c1 int, c2 int);
Cheers,
Greg
On 2/15/24 08:16, Greg Sabino Mullane wrote:
So as I also tested the same as you posted, there has been no change
in "ctid" , when I altered the column data type from 'int' to
'bigint' in the table, so that means full table rewriting
won't happen in such a scenario.
No it was de
>
> So as I also tested the same as you posted, there has been no change in
> "ctid" , when I altered the column data type from 'int' to 'bigint' in the
> table, so that means full table rewriting won't happen in such a scenario.
No it was definitely rewritten - do not depend on the ctid to verif
Hi,
On Thu, Feb 15, 2024 at 10:52:42AM +, Daniel Westermann (DWE) wrote:
>
> quick question: What would be the cases for a query_id in pg_stat_activity
> not showing up in pg_stat_statements.queryid assuming pg_stat_statements.max
> is not yet reached?
Well, first the query_id in pg_stat_acti
Hi,
quick question: What would be the cases for a query_id in pg_stat_activity not
showing up in pg_stat_statements.queryid assuming pg_stat_statements.max is not
yet reached?
Regards
Daniel
> On 14 Feb 2024, at 21:56, Tom Lane wrote:
> Ayush Vatsa writes:
>> 2. While going through the contrib folder I find that in the regress test
>> there are two .out files with respect to a single .sql file, example
>> citext.out and citext_1.out wrt citext.sql. Why is it so? Even in git blame
>>
21 matches
Mail list logo
