| From: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Peter Geoghegan <pg(at)bowt(dot)ie>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: pg14 psql broke \d datname.nspname.relname |
| Date: | 2022-01-26 17:04:15 |
| Message-ID: | E113768A-93CE-42F5-B654-CC12C2051AD9@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Jan 17, 2022, at 1:54 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> + * dotcnt: how many separators were parsed from the pattern, by reference.
> + * Can be NULL.
>
> But then:
>
> + Assert(dotcnt != NULL);
Removed the "Can be NULL" part, as that use case doesn't make sense. The caller should always care whether the number of dots was greater than they are prepared to handle.
> On a related note, it's unclear why you've added three new arguments
> to processSQLNamePattern() but only one of them gets a mention in the
> function header comment.
Updated the header comments to include all parameters.
> It's also pretty clear that the behavior of patternToSQLRegex() is
> changing, but the function header comments are not.
Updated the header comments for this, too.
Also, rebased as necessary:
| Attachment | Content-Type | Size |
|---|---|---|
| v5-0001-Reject-patterns-with-too-many-parts-or-wrong-db.patch | application/octet-stream | 75.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2022-01-26 17:31:06 | Re: refactoring basebackup.c |
| Previous Message | Andrew Dunstan | 2022-01-26 16:19:15 | Re: Non-decimal integer literals |