| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Vik Fearing <vik(at)postgresfriends(dot)org> |
| Cc: | Gurjeet Singh <gurjeet(at)singh(dot)im>, Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: MERGE ... RETURNING |
| Date: | 2023-11-01 17:49:02 |
| Message-ID: | f13b9adca2c668a3e4a8eae54cc2de64bc1e4c6f.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 2023-11-01 at 10:12 +0000, Dean Rasheed wrote:
> Something I'm wondering about is to what extent this discussion is
> driven by concerns about aspects of the implementation (specifically,
> references to function OIDs in code), versus a desire for a different
> user-visible syntax. To a large extent, those are orthogonal
> questions.
Most of my concern is that parts of the implementation feel like a
hack, which makes me concerned that we're approaching it the wrong way.
At a language level, I'm also concerned that we don't have a way to
access the before/after versions of the tuple. I won't insist on this
because I'm hoping that could be solved as part of a later patch that
also addresses UPDATE ... RETURNING.
> (As an aside, I would note that there are already around a dozen
> references to specific function OIDs in the parse analysis code, and
> a
> lot more if you grep more widely across the whole of the backend
> code.)
If you can point to a precedent, then I'm much more inclined to be OK
with the implementation.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2023-11-01 17:57:18 | Re: Confused about stream replication protocol documentation |
| Previous Message | Merlin Moncure | 2023-11-01 17:19:37 | Re: MERGE ... RETURNING |