Re: proposal: row_to_array function

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, 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-23 14:45:07
Message-ID: CAFj8pRA+hwL0NDy7bh4oaJRnNUqZxAZtB9KRd9556OhGLvN=+g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2015-06-23 1:56 GMT+02:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2015-06-23 14:53:06 Re: less log level for success dynamic background workers for 9.5
Previous Message Robert Haas 2015-06-23 14:23:16 Re: SSL TAP tests and chmod