Re: ('dog$house' = quote_ident('dog$house')) is surprisingly FALSE

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: ('dog$house' = quote_ident('dog$house')) is surprisingly FALSE
Дата
Msg-id CAKFQuwZzRmxiheLjSpTKSOjrt5w+qD6T73qSQ_BtBuoy3QQybg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: ('dog$house' = quote_ident('dog$house')) is surprisingly FALSE  (Bryn Llewellyn <bryn@yugabyte.com>)
Список pgsql-general
On Fri, Oct 7, 2022 at 5:16 PM Bryn Llewellyn <bryn@yugabyte.com> wrote:
david.g.johnston@gmail.com wrote:

bryn@yugabyte.com wrote:

(3) The PG doc on quote_ident says this in large friendly letters:

Quotes are added only if necessary…

Notice "only". I now know that this is very much not the case. You can compose an effectively unlimited number of different examples along these lines:

select quote_ident('redaktør'); → "redaktør"
create table redaktør(n int); → table successfully created

Yep, and that is precisely what would make for a good bug report. Pointing out that "if necessary" does not indeed match up with the behavior. I suspect it is likely to get changed - everything else being discussed just detracts attention from it.

*BRIEFLY*

What does "make for a good bug report" mean, David? Is it:

(1.1) You, David, or somebody else who has been officially recognized as a PG Contributor (https://www.postgresql.org/community/contributors/) will file the bug, granting it credibility with their imprimatur?


The research, evidence, and argument should be able to stand on their own.  With those qualities it doesn't really matter too much the reputation of the person filing.
 
or (1.2) I, Bryn, should file the bug.

I was providing some suggested wording for how your original email could have been written as a simple bug report.  And I definitely encourage people to take the time to consider and write good bug reports - while I do try and provide a community service in either writing or responding to such reports I am quite happy focusing on the later.
 

About "I suspect it is likely to get changed", do you mean:

(2.1) Change the doc to match quote_ident's current, unpredictable, behavior? (By all means, substitute "hard to describe accurately, precisely, and yet still tersely" for "unpredictable".)

The documentation would be my expectation, but the report doesn't need to presuppose either outcome, just point out the inconsistency.


(2.2) Change quote_ident's implementation—and then write new doc to describe the new behavior precisely and accurately? And for this option, the next question is "What's the spec of the changed implementation?"

Notice that the issue is broader than just quote_ident, as this test shows:


Then add that to the report - they do indeed seem to be of a similar nature.  If they weren't, then you'd have two bug reports.

I’m not convinced. The discussion has shown that some people are somewhat confused. For example, it was suggested that a name like this:


The follow-on conversation was likely to happen once the "why" of the inconsistency started to be discussed.


Compare this with the implementation that I thought, at first, that I could use when I simply believed the doc. (The subject line of this thread hits at the trivial SQL statement that would implement the "language SQL" function.) ANd if that's all there is to it, then when not ship is as a built-in?

I just suggest you separate straight-forward seeming bugs from philosophical discussions.  This was a good example of a situation that was simple enough to be a bug - whether the docs or code get changed is what the bug report follow-up from the community is meant to work out.

David J.

В списке pgsql-general по дате отправления:

Предыдущее
От: Christophe Pettus
Дата:
Сообщение: Re: ('dog$house' = quote_ident('dog$house')) is surprisingly FALSE
Следующее
От: Ron
Дата:
Сообщение: Re: pg_restore creates public schema?