Re: ICU, locale and collation question

On 10.05.23 07:02, Kirk Wolak wrote: On Tue, May 9, 2023 at 11:24 AM Peter Eisentraut > wrote: On 09.05.23 08:54, Oscar Carlberg wrote: > Our initdb setup would then look like this for compatibility; > -E 'UTF-8' > --locale-provider=i

Re: ICU, locale and collation question

On Tue, May 9, 2023 at 11:24 AM Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote: > On 09.05.23 08:54, Oscar Carlberg wrote: > > Our initdb setup would then look like this for compatibility; > > -E 'UTF-8' > > --locale-provider=icu > > --icu-locale=sv-SE-x-icu > > --lc_monetary=sv_SE.UT

Re: Return rows in input array's order?

On Tue, May 9, 2023 at 6:36 AM David Wheeler wrote: > > >> It was only used for small arrays but never noticed any performance > issues > > > > Hmmm, sounds like this would be quadratic though... > > True, but it’s cpu time not io, which tends to be orders of magnitude > slower > > > I wonder whe

Re: "PANIC: could not open critical system index 2662" - twice

On Sun, May 7, 2023 at 10:18 PM Thomas Munro wrote: > On Mon, May 8, 2023 at 4:10 AM Evgeny Morozov > wrote: > > On 6/05/2023 11:13 pm, Thomas Munro wrote: > > > Would you like to try requesting FILE_COPY for a while and see if it > eventually happens like that too? > > Sure, we can try that. >

Re: Return rows in input array's order?

On Tue, 9 May 2023 11:37:29 +0200 Dominique Devienne wrote: > On Tue, May 9, 2023 at 11:23 AM David Wheeler > wrote: > > > > Hi. With an integer identity primary key table, > > > we fetch a number of rows with WHERE id = ANY($1), > > > with $1 an int[] array. The API using that query must retur

Re: ICU, locale and collation question

On 09.05.23 08:54, Oscar Carlberg wrote: Our initdb setup would then look like this for compatibility; -E 'UTF-8' --locale-provider=icu --icu-locale=sv-SE-x-icu --lc_monetary=sv_SE.UTF-8 --lc-numeric=sv_SE.UTF-8 --lc-time=sv_SE.UTF-8 --lc-messages=en_US.UTF-8 Should we still provide createdb wit

Re: ICU, locale and collation question

On Tue, 2023-05-09 at 08:54 +0200, Oscar Carlberg wrote: > Should we still provide createdb with --lc-collate=C and --lc-ctype=C, > or should we set those to sv_SE.UTF-8 as well? That depends on whether you want Swedish or binary sort order (is "a" < "Z" or not?). The C collation is not good for

Re: Return rows in input array's order?

>> It was only used for small arrays but never noticed any performance issues > > Hmmm, sounds like this would be quadratic though... True, but it’s cpu time not io, which tends to be orders of magnitude slower > I wonder whether the int[] can be turned into a pseudo table with a ROWNUM > ext

Re: Return rows in input array's order?

Hi Dominique: Take a look to the "unnest()" function. It transforms an array into a set of rows. I believe I used it in the past to do something similar to what you need. Another option is to use a "values" expression (in a subquery) instead of an array, and build the query dynamically. Be

Re: Return rows in input array's order?

On Tue, May 9, 2023 at 11:23 AM David Wheeler wrote: > > Hi. With an integer identity primary key table, > > we fetch a number of rows with WHERE id = ANY($1), > > with $1 an int[] array. The API using that query must return > > rows in the input int[] array order, and uses a client-side > > mapp

Re: Return rows in input array's order?

> Hi. With an integer identity primary key table, > we fetch a number of rows with WHERE id = ANY($1), > with $1 an int[] array. The API using that query must return > rows in the input int[] array order, and uses a client-side > mapping to achieve that currently. > > Is it possible to maintain

Return rows in input array's order?

Hi. With an integer identity primary key table, we fetch a number of rows with WHERE id = ANY($1), with $1 an int[] array. The API using that query must return rows in the input int[] array order, and uses a client-side mapping to achieve that currently. Is it possible to maintain $1's order direc

Re: "PANIC: could not open critical system index 2662" - twice

On 8/05/2023 11:04 pm, Andres Freund wrote: > Are you using any extensions? Only plpgsql. > Do you have any chance to figure out what statements were running > concurrently with the DROP DATABASE? No. Is there some way to log that, other than just logging all statements (which seems impractical)?