Re: Missing table from in INSERT RETURNING

From: Rémi Cura <remi(dot)cura(at)gmail(dot)com>
To: John McKown <john(dot)archie(dot)mckown(at)gmail(dot)com>
Cc: PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Missing table from in INSERT RETURNING
Date: 2015-02-18 14:55:54
Message-ID: CAJvUf_vX0TOJq1o0GYWiD-yBq3Q2qVAcpRPcokrx3_Lb=YO3dw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hey folks,
thanks for the answers.
As you guessed it is just a synthetic example,
(so of course RETURNING some_value / 10 is possible in this case, but not
in general when the function is much more complicated than "/10").
Same wise, adding a column is just not a serious option.

It correspond to a real need that is that you have rows associated to an
*id*.
Now you want to insert part of this row into a table with a serial field (
*gid*).
Upon insertion, the serial field is automatically filled, and you get it
with a returning statement.
The problem is that you have no way to know which value of *gid* is
associated to which *id*.

The other workaround I found is to get nextvalue() before insert to to know
beforehand what will be the *(gid, id)* association.

It is suboptimal and ugly, so I would prefer another solution.

Cheers,
Rémi-C

2015-02-17 21:33 GMT+01:00 John McKown <john(dot)archie(dot)mckown(at)gmail(dot)com>:

> On Tue, Feb 17, 2015 at 2:15 PM, David G Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
>> On Tue, Feb 17, 2015 at 1:08 PM, John McKown [via PostgreSQL] <[hidden
>> email] <http:///user/SendEmail.jtp?type=node&node=5838309&i=0>> wrote:
>>
>>> I haven't seen any one else reply. I don't know if you've gotten a
>>> solution. But the following seemed to work for me:
>>>
>>>
>> ​mine apparently got bounced...​
>>
>>
>>
>>> WITH serie AS (
>>> select s, s*10 as computing
>>> from generate_series(1,10) as s
>>> )
>>> INSERT INTO test_insert_returning (some_value)
>>> SELECT computing
>>> FROM serie
>>> RETURNING gid, some_value;
>>>
>>
>> ​or, "RETURNING some_value / 10"​
>>
>>
>>> From my reading on the RETURNING phrase, you can only return values from
>>> the table into which you are doing the INSERT. Not any other table or view
>>> which might be referenced.
>>>
>>>
>> ​This is correct; and I am curious on the use case that requires
>> otherwise.​
>>
>
> ​A weird one might be where in data available ("s") in the CTE is in
> English measure (feet, miles, etc) and the OP wants to insert the
> equivalent Metric value ("computing") into the table, but needs to return
> the English value to the caller (why?). He does not want to put the English
> measure into the table itself, just to be able to return it. And not need
> to do a reverse conversion. As I said, just a weird thought. From a
> effervescent fount of weird thoughts - me. Or perhaps what he is storing in
> the table is a one-way hash of a password, and wants to return the
> clear-text password to the caller? Hum, that is almost reasonable. I'll
> need to be more on guard.
>
>
>
>>
>> ​David J.​
>>
>>
>
>
> --
> He's about as useful as a wax frying pan.
>
> 10 to the 12th power microphones = 1 Megaphone
>
> Maranatha! <><
> John McKown
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Medhavi Mahansaria 2015-02-18 15:06:45 #Personal#: Reg: Multiple queries in a transaction
Previous Message Andres Freund 2015-02-18 13:18:35 Re: BDR Monitoring, missing pg_stat_logical_decoding view