John Gray <jgray@azuli.co.uk> writes:
> I've had a look, and it seems that AlterTableAlterColumnStatistics
> contains a lot of template code (and only a small amount actually
> dealing with stats). If we had different Node types for the different
> Column flag-changing operations (especially those which don't touch
> tuple data at all) then the current AlterTableAlterColumnStatistics
> might become AlterTableAlterColumnFlags (?) and take several kinds of
> nodes. Thus all the inheritance-supporting code wouldn't need to be
> duplicated. Alternatively, cloning the routine wouldn't be too much
> work.
Sounds like a great idea --- the ALTER TABLE code has kind of grown
without supervision over the past few releases, since cut-and-paste
was the easiest starting point for implementing any new variant.
Some creative refactoring would help it out a lot. Go for it, if
you feel like doing that.
[ back to original subject ]
>> Have you got any ideas about the update side of the problem?
> What I'm not sure about is the syntax for specifying such an update.
Yup, that's the key part of the problem.
> Would we just overload the syntax for an array?
> e.g. UPDATE objects SET obj_data[32:47]='0123456789abcdef';
This makes lots of sense for bytea, which ought to be considered an
array type anyway, but I'm less certain about doing it that way for
multibyte text objects. Seems like it could be pretty inefficient
if the subscriptable entities are of varying length. Ideas anyone?
> I can see the other problem being that an updated toast value currently
> gets a new valueid.
Not sure if this is necessary or not. Jan?
regards, tom lane
