Re: [PATCH] Add --syntax to postgres for SQL syntax checking

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [PATCH] Add --syntax to postgres for SQL syntax checking
Дата
Msg-id CA+TgmoZTZh7sUKwvFemJ5kGDQ=cfsb-GPGe6r5m0m=+NGJBxUQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Add --syntax to postgres for SQL syntax checking  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PATCH] Add --syntax to postgres for SQL syntax checking
Список pgsql-hackers
On Wed, May 15, 2024 at 3:28 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Sorry: "make sense" was a poorly chosen phrase there.  What I was
> doubting, and continue to doubt, is that 100% checking of what
> you can check without catalog access and 0% checking of the rest
> is a behavior that end users will find especially useful.

You might be right, but my guess is that you're wrong. Syntax
highlighting is very popular, and seems like a more sophisticated
version of that same concept. I don't personally like it or use it
myself, but I bet I'm hugely in the minority these days. And EDB
certainly gets customer requests for syntax checking of various kinds;
whether this particular kind would get more or less traction than
other things is somewhat moot in view of the low likelihood of it
actually happening.

> I'm less enthusiatic about this than you are.  I think it would likely
> produce a slower and less maintainable system.  Slower because we'd
> need more passes over the query: what parse analysis does today would
> have to be done in at least two separate steps.  Less maintainable
> because knowledge about certain things would end up being more spread
> around the system.  Taking your example of getting syntax checking to
> recognize invalid EXPLAIN keywords: right now there's just one piece
> of code that knows what those options are, but this'd require two.
> Also, "run the first set of checks and then decide whether to proceed
> further" seems like optimizing the system for broken queries over
> valid ones, which I don't think is an appropriate goal.

Well, we've talked before about other problems that stem from the fact
that DDL doesn't have a clear separation between parse analysis and
execution. I vaguely imagine that it would be valuable to clean that
up for various reasons. But I haven't really thought it through, so
I'm prepared to concede that it might have various downsides that
aren't presently obvious to me.

> Now, I don't say that there'd be *no* benefit to reorganizing the
> system that way.  But it wouldn't be an unalloyed win, and so I
> share your bottom line that the costs would be out of proportion
> to the benefits.

I'm glad we agree on that much, and don't feel a compelling need to
litigate the remaining differences between our positions, unless you
really want to. I'm just telling you what I think, and I'm pleased
that we think as similarly as we do, despite remaining differences.

--
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: Robert Treat
Дата:
Сообщение: Re: [DOC] Add detail regarding resource consumption wrt max_connections
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [DOC] Add detail regarding resource consumption wrt max_connections