Re: Language options for GIN index support functions

Hi út 7. 2. 2023 v 3:49 odesílatel Phillip Diffley napsal: > Hello, > > The support functions and operator methods needed to extend a GIN index > are documented in C syntax > . Do > these functions need to be implemented in C, or i

Language options for GIN index support functions

Hello, The support functions and operator methods needed to extend a GIN index are documented in C syntax . Do these functions need to be implemented in C, or is there an interface for other languages like PL/pgSQL? Thanks! Phillip

Re: Understanding years part of Interval

> On 06/02/2023 18:33 CET Marcos Pegoraro wrote: > > Em seg., 6 de fev. de 2023 às 10:59, Erik Wienhold escreveu: > > > On 06/02/2023 12:20 CET Marcos Pegoraro wrote: > > > > > > I was just playing with some random timestamps for a week, for a month, > > > for a year ... > > > > > > select

Re: Sequence vs UUID

On 2023-02-06 20:04:39 +0100, Julian Backes wrote: > I don't really understand what you mean by 'performance'. To me it is not > surprising that incrementing (I know it is not just incrementing) a > 64bit integer is faster than generating 128 bit data with a good amount of > random data even if it

Re: Sequence vs UUID

I don't really understand what you mean by 'performance'. To me it is not surprising that incrementing (I know it is not just incrementing) a 64bit integer is faster than generating 128 bit data with a good amount of random data even if it seems to be too slow. So in my opinion you need to separate

Re: Question regarding UTF-8 data and "C" collation on definition of field of table

On 2023-02-05 18:57:13 -0600, Ron wrote: > Why are you specifying the collation to be "C" when the default db encoding > is UTF8, and UTF-8 has Greek, Chinese and English encodings? C is equally bad for Greek, Chinese and English ;-) hp -- _ | Peter J. Holzer| Story must make mo

Re: Sequence vs UUID

So, it may be the machine on which the code is getting executed behind the scene , in the site "https://dbfiddle.uk/"; is playing a key role in the speed, however, the comparative performance of UUID vs sequence should stay the same. So I think, after this test we can safely conclude that if we co

Re: plpgsql: ambiguous column reference in ON CONFLICT clause

po 6. 2. 2023 v 19:02 odesílatel David G. Johnston < david.g.johns...@gmail.com> napsal: > On Monday, February 6, 2023, Torsten Förtsch > wrote: > >> >> After reading this I am wondering if the current behavior is actually a >> bug. >> > > Arguably it is a bug, and a known one at that if you want

Re: Get the sequence name corresponding to a GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY column

... and I would like to automatically return the last generated identity, and also reset the sequence, if a value was specified explicitly for the identity column and this value is greater than the last generated value. With serial/bigserial/smallserial I am adding a returning clause to each INS

Re: Get the sequence name corresponding to a GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY column

I am writing generic code and don't know in advance the name of identity column. Only the table name is known (parsing of INSERT INTO tabname statement is easy) Column names may use uppercase or lowercase letters. I guess I could figure out what column is defined as identity, from pg_attrribut

Re: plpgsql: ambiguous column reference in ON CONFLICT clause

On Monday, February 6, 2023, Torsten Förtsch wrote: > > After reading this I am wondering if the current behavior is actually a > bug. > Arguably it is a bug, and a known one at that if you want some light reading, but regardless there is presently no proposal to get rid of the POLA violation an

Re: plpgsql: ambiguous column reference in ON CONFLICT clause

On 2/6/23 09:46, Torsten Förtsch wrote: Is there a way to prevent this from happening? I know I can use the PK constraint name or rename the OUT variable i. The question is can this be resolved while keeping the arbiter inference and the variable name. CREATE TABLE x.x (     i INT PRIMARY KEY

plpgsql: ambiguous column reference in ON CONFLICT clause

Is there a way to prevent this from happening? I know I can use the PK constraint name or rename the OUT variable i. The question is can this be resolved while keeping the arbiter inference and the variable name. CREATE TABLE x.x ( i INT PRIMARY KEY ); CREATE OR REPLACE FUNCTION x.ins(p_i INT

Re: Get the sequence name corresponding to a GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY column

Sebastien Flaesch schrieb am 06.02.2023 um 18:17: Assuming that a sequence is used to implement |GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY| Is there any built-in function that returns the underlying sequence name used for such column? Otherwise, an SQL query to return the sequence name?

Get the sequence name corresponding to a GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY column

Hello! Assuming that a sequence is used to implement GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY Is there any built-in function that returns the underlying sequence name used for such column? Otherwise, an SQL query to return the sequence name? I need the sequence name, in order to reset it

ALTER COLUMN to change GENERATED ALWAYS AS expression?

Hi all, I have a column defined GENERATED ALWAYS AS {my_expression} STORED. I’d like to change the {my_expression} part. After reading the documentation for ALTER TABLE (https://www.postgresql.org/docs/current/sql-altertable.html) and trying a few things that resulted in syntax errors, there doe

Re: Understanding years part of Interval

> On 06/02/2023 12:20 CET Marcos Pegoraro wrote: > > I was just playing with some random timestamps for a week, for a month, > for a year ... > > select distinct current_date+((random()::numeric)||'month')::interval from > generate_series(1,100) order by 1; > It´s with distinct clause because if

Understanding years part of Interval

I was just playing with some random timestamps for a week, for a month, for a year ... select distinct current_date+((random()::numeric)||'month')::interval from generate_series(1,100) order by 1; It´s with distinct clause because if you change that 'month' for a 'year' it´ll return only 12 rows,