On 2024-02-16 12:10:20 +0530, veem v wrote:
>
> 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 Fri, Feb 16, 2024 at 4:04 PM sud wrote:
>
> Yes these are Account number/PCI data and "data at rest" encryption is
> something management is asking to have irrespective of whether we encrypt
> those before storing in the database or not. And this system needs to
> adhere to PCI 4.0 standards ,
On Fri, Feb 16, 2024 at 4:04 PM sud wrote:
> On Fri, Feb 16, 2024 at 10:50 PM Greg Sabino Mullane
> wrote:
>
>> You need to clearly define your threat model. What exactly are you
>> defending against? What scenario do you want to avoid?
>>
>> Also, your decision of on-premise or Aurora is extrem
On Fri, Feb 16, 2024 at 10:50 PM Greg Sabino Mullane
wrote:
> You need to clearly define your threat model. What exactly are you
> defending against? What scenario do you want to avoid?
>
> Also, your decision of on-premise or Aurora is extremely relevant to your
> range of options.
>
>
Thank you
On Fri, Feb 16, 2024 at 1:53 AM sud wrote:
> 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.
The phrases "personal information" and "data at rest encryption" strongly
indicate PCI, or something similar.
On Fri, Feb 16, 2024 at 12:20 PM Greg Sabino Mullane
wrote:
> You need to clearly define your threat model. What exactly are you
> defending against? What scenario do you want to avoid?
On 2/16/24 10:10 AM, David G. Johnston wrote:
On Fri, Feb 16, 2024 at 10:24 AM Michael Corey
wrote:
By explicitly making a column an IDENTITY column it is going to
make a sequence behind the scenes even if one with a similar name
exists. I tried and it created part_tab_part_id_se
On Fri, Feb 16, 2024 at 10:24 AM Michael Corey
wrote:
> By explicitly making a column an IDENTITY column it is going to make a
> sequence behind the scenes even if one with a similar name exists. I tried
> and it created part_tab_part_id_seq1. Is there no way to have it use the
> original part_
By explicitly making a column an IDENTITY column it is going to make a
sequence behind the scenes even if one with a similar name exists. I tried
and it created part_tab_part_id_seq1. Is there no way to have it use the
original part_tab_part_id_seq? How do I get the data and the sequence in
sync
You need to clearly define your threat model. What exactly are you
defending against? What scenario do you want to avoid?
Also, your decision of on-premise or Aurora is extremely relevant to your
range of options.
Cheers,
Greg
On Fri, Feb 16, 2024 at 9:24 AM Michael Corey
wrote:
> If I run these two statements I get an error
> ERROR: relation "part_tab_part_id_seq" already exists
>
> I tried different combinations of this ALTER TABLE statement and none seem
> to work. What is the proper way to reattach the identity a
What is the proper way to deal with identity columns on a table
rebuild/partitioning? If I have the following non-partitioned table
CREATE TABLE IF NOT EXISTS part_tab
(
part_id bigint NOT NULL GENERATED BY DEFAULT AS IDENTITY ( INCREMENT 1
START 0 MINVALUE 0 MAXVALUE 9223372036854775807 CACH
12 matches
Mail list logo
