From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: row_to_array function |
Date: | 2015-06-22 23:56:35 |
Message-ID: | 5588A0B3.4060205@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6/22/15 2:46 AM, Pavel Stehule wrote:
>
> FOREACH key, val IN RECORD myrow
> LOOP
> IF pg_typeof(val) IN ('int4', 'double precision', 'numeric') THEN
> val := val + 1; -- these variables can be mutable
> -- or maybe in futore
> myrow[key] := val + 1;
> END IF;
> END LOOP;
>
> What is important - "val" is automatic variable, and it can has
> different type in any step.
>
> It is little bit strange, but impossible to solve, so we cannot to
> support row[var] as right value (without immutable casting). But we can
> do it with left value.
Actually, you can (theoretically) solve it for the right value as well
with if val is an actual type and you have operators on that type that
know to search for a specific operator given the actual types that are
involved. So if val is int4, val + 1 becomes int4 + int4.
The problem I've run into with this is by the time you've added enough
casts to make this workable you've probably created a situation where
val + something is going to recurse back to itself. I've partially
solved this in [1], and intend to finish it by calling back in via SPI
to do the final resolution, the same way the RI triggers do.
What would be a lot better is if we had better control over function and
operator resolution.
[1]
https://github.com/decibel/variant/commit/2b99067744a405da8a325de1ebabd213106f794f#diff-8aa2db4a577ee4201d6eb9041c2a457eR846
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2015-06-23 00:06:33 | Re: Hash index creation warning |
Previous Message | Jim Nasby | 2015-06-22 23:06:06 | Re: [Proposal] Progress bar for pg_dump/pg_restore |