> "Tom" == Tom Lane writes:
Tom> For example, suppose f(...) returns a single-column tuple result.
Tom> This should be legal, if x matches the type of the single column:
Tom> update ... set (x) = f(...)
Tom> but if we try to do what you seem to have in mind, this would not
Tom> be:
Tom>
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> As far as (a) goes, it was an intentional compatibility breakage,
> So here I have a problem: the fact that it was a compatibility breakage
> seems not to have been discussed *or even so much as mentioned* on
> -hackers at any time.
I wi
> "Justin" == Justin Pryzby writes:
>> It then apparently went unnoticed until after the release of pg 10,
>> at which point it got retroactively documented (in the release notes
>> and nowhere else), in response to a brief discussion of a user
>> complaint that happened on -general and n
On Wed, Jun 13, 2018 at 05:48:50AM +0100, Andrew Gierth wrote:
> It then apparently went unnoticed until after the release of pg 10, at
> which point it got retroactively documented (in the release notes and
> nowhere else), in response to a brief discussion of a user complaint
> that happened on -
On Wed, Jun 13, 2018 at 12:48 AM, Andrew Gierth
wrote:
> The original patch, a self-described "lazy-sunday project", made
> absolutely no mention of any compatibility issue, simply discussed the
> new options it was allowing, and got no feedback or review. Had it
> mentioned or even hinted that ex
[Pruning the CC list and moving this to -hackers]
> "Tom" == Tom Lane writes:
Tom> It's telling you what to do: use a ROW() expression, ie
Tom> update fvt_obj_operate_update_table_033 set (c_int) = row(20)
Tom> where c_int = 20;
>> Yeah, but (a) this used to work, and has worked since a
