From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Mikhail Titov <mlt(at)gmx(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [bug+patch] Inserting DEFAULT into generated columns from VALUES RTE |
Date: | 2020-11-23 14:45:18 |
Message-ID: | CAEZATCWSaNs9hihPBqxFqAQ-N0uqatPcPA118sUe9yxyEb4MTA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 22 Nov 2020 at 20:58, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> I found only one nitpicky bug: in
> findDefaultOnlyColumns, the test must be bms_is_empty(default_only_cols)
> not just default_only_cols == NULL, or it will fail to fall out early
> as intended when the first row contains some DEFAULTs but later rows
> don't.
Ah, good point. Thanks for fixing that.
> > I haven't touched the existing error messages. I think that's a
> > subject for a separate patch.
>
> Fair. After looking around a bit, I think that getting an error
> cursor as I'd speculated about is more trouble than it's worth.
> For starters, we'd have to pass down the query string into this
> code, and there might be some ticklish issues about whether a given
> chunk of parsetree came from that string or from some rule or view.
> However, I think that just adjusting the error string would be
> helpful, as attached.
+1
> (I'm also wondering why the second case is generic ERRCODE_SYNTAX_ERROR
> and not ERRCODE_GENERATED_ALWAYS. Didn't change it here, though.)
I can't see any reason for it to be different, and
ERRCODE_GENERATED_ALWAYS seems like the right code to use for both
cases.
Regards,
Dean
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-11-23 15:06:30 | Re: pg_proc.dat "proargmodes is not a 1-D char array" |
Previous Message | John Naylor | 2020-11-23 14:41:25 | Re: cutting down the TODO list thread |