Re: proposal: row_to_array function - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: row_to_array function
Date
Msg-id CAFj8pRA+hwL0NDy7bh4oaJRnNUqZxAZtB9KRd9556OhGLvN=+g@mail.gmail.com
Whole thread Raw
In response to Re: proposal: row_to_array function  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: proposal: row_to_array function  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers


2015-06-23 1:56 GMT+02:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
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

The solution of dynamic operators changes philosophy about 180° - and I afraid about a performance.

Now if I am thinking about possibilities - probably it is solvable on right side too. It needs to solve two steps:

1. parametrized record reference syntax - some like SELECT $1[$]
2. possibility to throw plan cache, if result has different type than is expected in cache.


Pavel

 
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX

Data in Trouble? Get it in Treble! http://BlueTreble.com

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: SSL TAP tests and chmod
Next
From: Pavel Stehule
Date:
Subject: Re: less log level for success dynamic background workers for 9.5