Horton

Re: [fixed] Trigger test

Dmitrii Bondar <d.bondar@postgrespro.ru>

View thread
From: Dmitrii Bondar <d.bondar@postgrespro.ru>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Paul Jungwirth <pj@illuminatedcomputing.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Lilian <ontowhee@gmail.com>
Date: 2025-04-04T05:45:37Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix some issues in contrib/spi/refint.c.

  2. I send you a attach of my modified refint.c that

On 04/04/2025 01:11, Tom Lane wrote:
> So that's a long laundry list and we haven't even dug hard.
> Is it worth it?  If you feel like doing the legwork then
> I'm willing to support the project, but I really wonder if
> we shouldn't cut our losses and just remove the module.
>
> (I hesitate now to look at the rest of contrib/spi/ :-()

You wrote a note that I decided to omit. As I mentioned, the patch does 
not even fix the cascade update problem—there are still broken 
cases—because it seems impossible to address it in a gentle way (the 
code was patched 20 years ago; it's truly legacy).

I considered removing it entirely, but that seemed too drastic a 
solution (and, at the very least, I don't have enough expertise to make 
that decision). If everything looks acceptable, I would prefer to cut 
the module. The |check_primary_key| and |check_foreign| functions are 
clearly unused, are buggy, and no one has reported any obvious 
problems—so refint.c can be safely removed. Autoinc.c also looks 
problematic.

There are some question. When should we remove the module? Should we 
mark it as deprecated for now and remove it later? Should we handle it 
in another thread? Should we apply this patch in that case?

Best regards,

Dmitrii