Hi,
On 2023-07-01 09:14:39 -0400, Andrew Dunstan wrote:
> On 2023-06-30 Fr 15:08, Tom Lane wrote:
> > Andrew Dunstan<andrew@dunslane.net> writes:
> > > Me either. I think this might call for too much invention so I'm going
> > > to revert to plan A. The invalidation code won't be very much, and it
> > > should be a fairly rare event, so it doesn't need to be very clever.
> > The problem with rarely-executed code is that it's also hard to test.
> Your Plan B in the end proved less difficult than I thought, and certainly
> seems more robust than having to tangle with invalidations. I didn't try to
> do anything to wrap the values in a bytea, it didn't seem necessary. Here's
> a patch - it's not terribly long or invasive. I haven't tried backpatching
> it yet.
Hm. Is tying this to top-level transactions the right choice? What about
sequences like
SAVEPOINT x; ALTER TABLE ... ADD COLUMN ... DEFAULT; SELECT use_default FROM ...; ROLLBACK TO SAVEPOINT x;
SAVEPOINT y; ALTER TABLE ... ADD COLUMN ... DEFAULT; SELECT use_default FROM ...; ROLLBACK TO SAVEPOINT y;
Isn't that going to break the assumption that the key is unique within a
transaction? I think at the very least you'd need to make
Separately, will this work correctly with procedures keeping values alive
across transactions? I don't feel like I have a good grasp at how that whole
area is supposed to work...
Greetings,
Andres Freund