| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
| Cc: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Problem with tupdesc in jsonb_to_recordset |
| Date: | 2018-07-11 11:30:48 |
| Message-ID: | 20180711113048.GF14301@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
On Wed, Jul 11, 2018 at 11:38:46AM +0100, Andrew Gierth wrote:
> My first approach - assuming that update_cached_tupdesc has good reason
> to make a copy, which I'm not convinced is the case - would be to simply
> make a per-query-context copy of the tupdesc to assign to rsi.setDesc in
> order to conform to the call protocol.
I see what you are coming at here, thanks for the input. I am not
really convinced that update_cached_tupdesc needs to do a new copy
either, but let's see what Tom has to say on the matter. That's his
feature and his code.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Gierth | 2018-07-11 12:03:41 | Re: BUG #15273: Lexer bug with UESCAPE |
| Previous Message | Andrew Gierth | 2018-07-11 10:38:46 | Re: Problem with tupdesc in jsonb_to_recordset |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2018-07-11 11:37:20 | Re: Negotiating the SCRAM channel binding type |
| Previous Message | Ashutosh Bapat | 2018-07-11 11:28:18 | Re: Preferring index-only-scan when the cost is equal |