pkg: two postgresql clients

Hello, 1. pkg upgrade show this result: New packages to be INSTALLED: postgresql13-client: 13.7 postgresql15-client: 15.b1_1 Installed packages to be UPGRADED: firefox: 103.0.1,2 -> 103.0.2,2 nspr: 4.34 -> 4.34.1 opencore-amr: 0.1.5 -> 0.1.6 py39-p

Re: index row size 2720 exceeds btree version 4

Am 10.08.22 06:57 schrieb(en) Daulat: We are facing an error while uploading data in a table that has two B-tree indexes. As per the Postgres documentation there is a limitation of b-tree index size but I need to know if there is any alternative to overcome this issue. [snip] UNIQUE INDEX uk_gv

Re: pkg: two postgresql clients

On Wed, Aug 10, 2022 at 09:25:37AM +0200, m...@ft-c.de wrote: Hi Franz, You will get much better targeted help with such questions at https://forums.freebsd.org (if it is FreeBSD you're running) or in German on https://www.bsdforen.de/ (for all tastes of Berkekey). Something is apparently wrong

Re: index row size 2720 exceeds btree version 4

On 2022-08-10 10:27:46 +0530, Daulat wrote: > Error: > > " index row size 2720 exceeds btree version 4 maximum 2704 for index > ""uk_gvoa_gi_ad"" 54000" > uk_gvoa_gi_ad > > Index: > > UNIQUE INDEX pk_gvoa_id ON test.groupedvuln_asset USING btree > (groupedvuln_orphanasset_id)" > > UNIQUE INDEX

Surprisingly forgiving behavior when a case expression is terminated with "end case"

The account of the CASE expression here: https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-CASE says that it's terminated with the keyword END (just as I've always understood)—i.e. not with the PL/pgSQL CASE statement's END CASE. Moreover CASE is a reserved word—as a

Re: Surprisingly forgiving behavior when a case expression is terminated with "end case"

Bryn Llewellyn writes: > Moreover CASE is a reserved word—as a "create table case(…)" attempt shows. > Yet CASE is tolerated (using PG 14.4) here: > select 1 as case; > In fact, any reserved word that I try (like IF, THEN, and so on) is accepted > as an alias. This seems to me to be wrong. Wha

Re: Surprisingly forgiving behavior when a case expression is terminated with "end case"

On 8/10/22 11:59, Bryn Llewellyn wrote: The account of the CASE expression here: https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-CASE says that it's terminated with the keyword END

Why is DEFAULT much faster than UPDATE?

This question is out of curiosity, just to learn more about the internals of PostgreSQL. The goal was to add a not null bool column filled with "false", but with "true" as the default for new rows. The naïve approach would be: ALTER TABLE foo ADD COLUMN slow bool NOT NULL DEFAULT true; UPDATE foo

Re: Why is DEFAULT much faster than UPDATE?

On 8/10/22 16:02, André Hänsel wrote: This question is out of curiosity, just to learn more about the internals of PostgreSQL. The goal was to add a not null bool column filled with "false", but with "true" as the default for new rows. The naïve approach would be: ALTER TABLE foo ADD COLUMN slo

Re: Surprisingly forgiving behavior when a case expression is terminated with "end case"

t...@sss.pgh.pa.us wrote: > I think we've spent a great deal of blood, sweat, and tears making that so, > or as nearly so as we could. We will in fact take any keyword after "AS", and > in recent versions many non-reserved keywords will work that way without "AS". > > (Mind you, I think the SQL

Surprising results from current_role in a "security invoker" trigger function in a "cascade delete via FK" scenario

My code example ended up quite big—so I'll show it to you all only if you ask. But it's easy to describe. My script does this: 1. It creates three non-superuser roles: "data", "code", and "client". 2. It creates a text-book masters-and-details table pair with owner "data". Each table has the ob

Re: Surprising results from current_role in a "security invoker" trigger function in a "cascade delete via FK" scenario

On Wed, Aug 10, 2022 at 6:53 PM Bryn Llewellyn wrote: > My code example ended up quite big—so I'll show it to you all only if you > ask. But it's easy to describe. My script does this: > Then maybe you should spend some time making a smaller code example that still shows the desired behavior but

Re: Surprising results from current_role in a "security invoker" trigger function in a "cascade delete via FK" scenario

david.g.johns...@gmail.com wrote: > …you should spend some time making a smaller code example that still shows > the desired behavior but can be easily read and executed by others. In > particular, your description of simply returning NULL for all triggers seems > suspect. If only two of the ei