Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?

It is in epas15, but for the whole cluster. Different keys for each database is not possible, how should it works for instance the wal - stream? On 18 May 2023 00:35:39 CEST, Tony Xu wrote: >Hi There, > >The FAQ (copied below) mentioned that native transparent data encryption >might be included

Is there a good way to handle sum types (or tagged unions) in PostgreSQL?

Hi, Is there any nice way to handle sum types (aka tagged unions) in a PostgreSQL database? I've searched far and wide and have not reached any satisfying answer. As a (somewhat contrived) example, say I have the following enum in Rust: enum TaggedUnion { Variant1(String), Variant2(i32),

JSONB operator unanticipated behaviour

Hello, I have encountered unanticipated behaviour with a JSONB operator, and wanted to make sure I am not misunderstanding its intended use. When using the @> operator, I get this result. select '{"a": [1]}'::jsonb @> '{"a": []}'::jsonb; ?column? -- t (1 row) However, given the phrasi

Re: Is there a good way to handle sum types (or tagged unions) in PostgreSQL?

On 5/18/23 05:27, Victor Nordam Suadicani wrote: Hi, Is there any nice way to handle sum types (aka tagged unions) in a PostgreSQL database? I've searched far and wide and have not reached any satisfying answer. As a (somewhat contrived) example, say I have the following enum in Rust: enum

Re: JSONB operator unanticipated behaviour

On 5/18/23 06:17, Brian Mendoza wrote: Hello, I have encountered unanticipated behaviour with a JSONB operator, and wanted to make sure I am not misunderstanding its intended use. When using the @> operator, I get this result. select '{"a": [1]}'::jsonb @> '{"a": []}'::jsonb;  ?column?

Re: JSONB operator unanticipated behaviour

Ah, yes, that seem to be the explanation! So it would seem that indeed it was my misunderstanding of the operator. select '{"a": [1,2]}'::jsonb @> '{"a": [1]}'::jsonb; ?column? -- t (1 row) select '{"a": [1,2]}'::jsonb @> '{"a": [2,1,2]}'::jsonb; ?column? -- t (1 row) I was

Re: JSONB operator unanticipated behaviour

Brian Mendoza writes: > Ah, yes, that seem to be the explanation! > So it would seem that indeed it was my misunderstanding of the operator. You seem to be reading some fairly old version of the documentation. The extended definition that Adrian mentions has been there for awhile, but the JSON op

Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?

Greetings, * Tony Xu (tony...@rubrik.com) wrote: > The FAQ (copied below) mentioned that native transparent data encryption > might be included in 16. Is it fair to assume that it will support database > level encryption, that is, we can use two encryption keys for two databases > in the same serv

Re: JSONB operator unanticipated behaviour

On 5/18/23 08:46, Tom Lane wrote: Brian Mendoza writes: Ah, yes, that seem to be the explanation! So it would seem that indeed it was my misunderstanding of the operator. You seem to be reading some fairly old version of the documentation. The extended definition that Adrian mentions has been

Re: JSONB operator unanticipated behaviour

Adrian Klaver writes: > On 5/18/23 08:46, Tom Lane wrote: >> You seem to be reading some fairly old version of the documentation. >> The extended definition that Adrian mentions has been there for >> awhile, but the JSON operator table didn't link to it before v13. >> (I agree that the "top level"

Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?

Thanks for the information, Andreas, Stephen. Our use-case is for a multi-tenancy scenario - we are considering using different databases to store different customer's data, however, for cost-efficiency, we want to host them in the same server (to reduce the CPU/mem idle time and to reduce the se

Unrecognized Node Type Warning

We are using PostgreSQL 12.13. We are noticing that queries that attempt to retrieve an element of an array by specifying its position cause a warning to be emitted: "WARNING: unrecognized node type: 110". Would appreciate your help diagnosing the issue and identifying steps to resolve. Queri

Re: JSONB operator unanticipated behaviour

On 5/18/23 09:36, Tom Lane wrote: Adrian Klaver writes: On 5/18/23 08:46, Tom Lane wrote: You seem to be reading some fairly old version of the documentation. The extended definition that Adrian mentions has been there for awhile, but the JSON operator table didn't link to it before v13. (I ag

Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?

On 5/18/23 10:54, Stephen Frost wrote: Greetings, * Tony Xu (tony...@rubrik.com) wrote: The FAQ (copied below) mentioned that native transparent data encryption might be included in 16. Is it fair to assume that it will support database level encryption, that is, we can use two encryption keys

Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?

On 5/18/23 11:49, Ron wrote: On 5/18/23 10:54, Stephen Frost wrote: Greetings, * Tony Xu (tony...@rubrik.com) wrote: The FAQ (copied below) mentioned that native transparent data encryption might be included in 16. Is it fair to assume that it will support database level encryption, that is, w

Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?

On Thu, 18 May 2023, Tony Xu wrote: >Our use-case is for a multi-tenancy scenario - we are considering using >different databases to store different customer's data, however, for Why not using multiple clusters then? Better isolation of the customers, but still on one server. bye, //mirabilos -

Re: Unrecognized Node Type Warning

"Arora, Nick" writes: > We are using PostgreSQL 12.13. We are noticing that queries that attempt to > retrieve an element of an array by specifying its position cause a warning to > be emitted: "WARNING: unrecognized node type: 110". I don't see that here, so I'm guessing it's coming from some

Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?

Thorsten Glaser writes: > On Thu, 18 May 2023, Tony Xu wrote: >> Our use-case is for a multi-tenancy scenario - we are considering using >> different databases to store different customer's data, however, for > Why not using multiple clusters then? Yeah. The problem with key-per-database is wha

Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?

On 5/18/23 13:02, Thorsten Glaser wrote: On Thu, 18 May 2023, Tony Xu wrote: Our use-case is for a multi-tenancy scenario - we are considering using different databases to store different customer's data, however, for Why not using multiple clusters then? Yet More Firewall Rules to get appro

Re: Unrecognized Node Type Warning

Hello Tom, Thanks for the information. Here are the extensions we are using: uuid-ossp pgcrypto citext btree_gin The warnings did start emitting shortly after the installation of btree_gin, so it seems somewhat suspect From: Tom Lane Date: Thursday, May 18, 2023 at 11:30 AM To: Arora, Nick

Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?

On 5/18/23 12:54, Rob Sargent wrote: On 5/18/23 11:49, Ron wrote: On 5/18/23 10:54, Stephen Frost wrote: Greetings, * Tony Xu (tony...@rubrik.com) wrote: The FAQ (copied below) mentioned that native transparent data encryption might be included in 16. Is it fair to assume that it will support

Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?

On Thu, 18 May 2023, Ron wrote: >> Why not using multiple clusters then? > > Yet More Firewall Rules to get approved by the Security Team.  And then they > balk at port 5433 because they've never heard of it. But mixing multiple customers on one cluster is much more of a risk. > And from a techn

Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?

On 5/18/23 11:56, Ron wrote: On 5/18/23 12:54, Rob Sargent wrote: On 5/18/23 11:49, Ron wrote: We need to keep costs down, too. Oracle (I think) does it at the DB level, and so does SQL Server. Upper Management hears us say "sorry, no can do" and wonders what bunch of amateurs are developi

Re: Unrecognized Node Type Warning

To provide more complete information: Here is the name and version of each extension we have installed: azure (1.0) btree_gin (1.3) citext (1.6) pgcrypto (1.3) plpgsql (1.0) uuid-ossp (1.1) This email and any attachments thereto may contain private, confidential, and privileged material fo

Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?

On 5/18/23 14:07, Thorsten Glaser wrote: On Thu, 18 May 2023, Ron wrote: Why not using multiple clusters then? Yet More Firewall Rules to get approved by the Security Team.  And then they balk at port 5433 because they've never heard of it. But mixing multiple customers on one cluster is much

PostgreSQL 13 - Logical Replication - ERROR: could not receive data from WAL stream: SSL SYSCALL error: EOF detected

Hello everyone, I have a replication between PostgreSQL 12 to 13 in the production system. Using Ubuntu 18.04 LTS We have this error today. *2023-05-18 18:34:04.374 WAT [117322] ERROR: could not receive data from WAL stream: SSL SYSCALL error: EOF detected2023-05-18 18:34:04.381 WAT [118393] L

Re: Unrecognized Node Type Warning

"Arora, Nick" writes: > Here is the name and version of each extension we have installed: > azure (1.0) > btree_gin (1.3) > citext (1.6) > pgcrypto (1.3) > plpgsql (1.0) > uuid-ossp (1.1) I'm quite certain that none of the last five are causing this, so you need to take it up with whoever p

Re: Is there a good way to handle sum types (or tagged unions) in PostgreSQL?

A composite type is a *product type* , not a sum type . PostgreSQL currently has great support for product types, but basically no support for sum types. >From the perspective of algebraic data types, this feels

Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?

On Thu, May 18, 2023 at 01:56:48PM -0500, Ron wrote: > We need to keep costs down, too. > > Oracle (I think) does it at the DB level, and so does SQL Server.  Upper > Management hears us say "sorry, no can do" and wonders what bunch of amateurs > are developing PostgreSQL. I have found it is hard

Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?

On 5/18/23 15:56, Bruce Momjian wrote: On Thu, May 18, 2023 at 01:56:48PM -0500, Ron wrote: We need to keep costs down, too. Oracle (I think) does it at the DB level, and so does SQL Server.  Upper Management hears us say "sorry, no can do" and wonders what bunch of amateurs are developing Post

Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?

Greetings, Please don't top-post on these lists. * Tony Xu (tony...@rubrik.com) wrote: > Our use-case is for a multi-tenancy scenario - we are considering using > different databases to store different customer's data, however, for > cost-efficiency, we want to host them in the same server (to re

Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?

Thanks all for the discussions. New to PostgreSQL so don't have much context here. Regarding the multiple clusters idea, how does that work? Assume we can store one customer's data in one cluster, is it possible to have separate KEK for different clusters? Why not using multiple clusters then? B

Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?

Greetings, Really, please don't top-post on these lists. * Tony Xu (tony...@rubrik.com) wrote: > Regarding the multiple clusters idea, how does that work? Assume we can > store one customer's data in one cluster, is it possible to have separate > KEK for different clusters? In the proposed TDE w

Re: PostgreSQL 13 - Logical Replication - ERROR: could not receive data from WAL stream: SSL SYSCALL error: EOF detected

At Thu, 18 May 2023 21:00:08 +0100, FOUTE K. Jaurès wrote in > Hello everyone, > > I have a replication between PostgreSQL 12 to 13 in the production system. > Using Ubuntu 18.04 LTS > We have this error today. > > > > *2023-05-18 18:34:04.374 WAT [117322] ERROR: could not receive data from

a simple-minded question about updating

I work with Postgres and wonder whether for my purposes there is a good-enough reason to update one of these days. I’m an editor working with some 60,000 Early Modern texts, many of them in need of some editorial attention. The texts are XM encoded documents. Each word is wrapped in a element

Re: a simple-minded question about updating

On 5/18/23 21:08, Martin Mueller wrote: I work with Postgres and wonder whether for my purposes there is a good-enough reason to update one of these days. Since you have not mentioned the Postgres version you are on now, there is really no definitive way to answer this. Though as a rule keep

Records, Types, and Arrays

Greetings, all. It's been a down-the-rabbit-hole day for me. It all started out with a simple problem. I have defined a composite type. There are functions which return arrays whose values would be suitable to the type I defined. How do I turn arrays into composite typed values? Conceptually,

Re: Records, Types, and Arrays

On Thu, May 18, 2023 at 10:06 PM Raymond Brinzer wrote: > How do I turn arrays into composite typed values? > Using just SQL syntax and no string munging: (array_val[1]::col1_type, array_val[2]::col2_type)::composite_type > While the second point is rather far-reaching and idealistic, the fir

Re: Records, Types, and Arrays

On Fri, May 19, 2023 at 1:42 AM David G. Johnston < david.g.johns...@gmail.com> wrote: > On Thu, May 18, 2023 at 10:06 PM Raymond Brinzer > wrote: > >> How do I turn arrays into composite typed values? >> > > Using just SQL syntax and no string munging: > > (array_val[1]::col1_type, array_val[2]:

Re: pg_stats.avg_width

Thanks, that makes sense. It was going to be my third guess, but it seemed pretty wide for a TOAST pointer. Reviewing what goes in there, though, it's reasonable. I assume that this means for unTOASTed but compressed data, this counts the compressed size. Would a doc patch clarifying this (and po

Re: Records, Types, and Arrays

On a problem which came up while trying to implement a solution, perhaps someone could explain this: scratch=# create type test_type as (a int, b int); CREATE TYPE scratch=# create function get_row() returns record as $$ select row(2,3); $$ language sql; CREATE FUNCTION scratch=# select get_row();

Re: Records, Types, and Arrays

On Thursday, May 18, 2023, Raymond Brinzer wrote: > > scratch=# select row(2,3)::test_type; > Unknown typed value, immediately converted to a known concrete instance of test_type. It is never actually resolved as record. All of the others must concretely be resolved to record to escape their qu

Re: Records, Types, and Arrays

Sorry, I should have noted this as well: "One should also realize that when a PL/pgSQL function is declared to return type record, this is not quite the same concept as a record variable, even though such a function might use a record variable to hold its result. In both cases the actual row struc