Re: Move tests of contrib/spi/ out of the core regression tests

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Move tests of contrib/spi/ out of the core regression tests
Date: 2025-04-08 19:51:54
Message-ID: 350fb18c-dce6-4db3-aed7-ac8711c9ab62@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 08/04/2025 16:55, Tom Lane wrote:
> Well, I don't mind pushing it, but does anyone want to review
> it first? It sounded like Heikki had at least eyeballed the
> patch, but I'm not sure if he's ready to sign off on it.

It looks good to me.

> diff --git a/doc/src/sgml/contrib-spi.sgml b/doc/src/sgml/contrib-spi.sgml
> index 55d3fac7a69..6fa9479d1b9 100644
> --- a/doc/src/sgml/contrib-spi.sgml
> +++ b/doc/src/sgml/contrib-spi.sgml
> @@ -81,10 +81,12 @@
> <para>
> <function>autoinc()</function> is a trigger that stores the next value of
> a sequence into an integer field. This has some overlap with the
> - built-in <quote>serial column</quote> feature, but it is not the same:
> - <function>autoinc()</function> will override attempts to substitute a
> - different field value during inserts, and optionally it can be
> - used to increment the field during updates, too.
> + built-in <quote>serial column</quote> feature, but it is not the same.
> + The trigger will replace the field's value only if that value is
> + initially zero or null (after the action of the SQL statement that
> + inserted or updated the row). Also, if the sequence's next value is
> + zero, <function>nextval()</function> will be called a second time in
> + order to obtain a non-zero value.
> </para>

That's a much clearer explanation of the behavior, but now that I read
that paragraph, I wonder *why* it behaves like that. I'm sure it's just
historical reasons. But perhaps we should nuke autoinc altogether?

--
Heikki Linnakangas
Neon (https://neon.tech)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2025-04-08 20:12:33 Re: [PoC] Reducing planning time when tables have many partitions
Previous Message Heikki Linnakangas 2025-04-08 19:41:31 Re: pgsql: Make cancel request keys longer