From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> |
Cc: | Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: CURRENT OF causes an error when IndexOnlyScan is used |
Date: | 2018-03-16 21:34:06 |
Message-ID: | 1850.1521236046@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> In the meantime, we could fix execCurrent.c so that it throws
> FEATURE_NOT_SUPPORTED rather than the current failure if the slot it's
> looking at doesn't contain a physical tuple.
Concretely, I think we should do the attached, so as to cover any other
situations where the scan type doesn't return a physical tuple. I kept
it separate from your patch so it's easy to test (the original case you
gave now throws the appropriate error).
The existing error when execCurrentOf can't figure out what to do with
the plan is ERRCODE_INVALID_CURSOR_STATE with message
"cursor \"%s\" is not a simply updatable scan of table \"%s\""
so for this draft patch I just used that. I'm not sure if it would be
a better idea to throw a different SQLSTATE or different error text
for this case. Any thoughts on that?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
handle-where-current-of-failure-better.patch | text/x-diff | 3.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Claudio Freire | 2018-03-16 21:46:06 | Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem |
Previous Message | Andres Freund | 2018-03-16 21:28:51 | Re: ON CONFLICT DO UPDATE for partitioned tables |