On 15.05.24 21:05, Robert Haas wrote:
I don't think it's at all obvious that this belongs on the server side
rather than the client side. I think it could be done in either place,
or both. I just think we don't have the infrastructure to do it
cleanly, at present.
I think if you're going to do
On Wed, 2024-05-15 at 14:39 -0400, Tom Lane wrote:
> The thing that was bothering me most about this is that I don't
> understand why that's a useful check. If I meant to type
>
> UPDATE mytab SET mycol = 42;
>
> and instead I type
>
> UPDATEE mytab SET mycol = 42;
>
> your
On Wed, May 15, 2024 at 6:35 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
>
> If in core I would still want to expose this as say a contrib module
> binary instead of hacking it into postgres. It would be our first server
> program entry there.
>
>
Sorry for self-reply but:
Maybe
On Wed, May 15, 2024 at 1:00 PM Robert Haas wrote:
> On Wed, May 15, 2024 at 3:28 PM Tom Lane 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
On Wed, May 15, 2024 at 3:28 PM Tom Lane 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
"David G. Johnston" writes:
> Now, in my ideal world something like this could be made as an extension so
> that it can work on older versions and not have to be maintained by core.
> And likely grow more features over time. Is there anything fundamental
> about this that prevents it being
On Wed, May 15, 2024 at 12:35 PM Josef Šimánek
wrote:
> st 15. 5. 2024 v 21:33 odesílatel David G. Johnston
> napsal:
>
> > Now, in my ideal world something like this could be made as an extension
> so that it can work on older versions and not have to be maintained by
> core. And likely grow
st 15. 5. 2024 v 21:33 odesílatel David G. Johnston
napsal:
>
> On Wed, May 15, 2024 at 12:18 PM wrote:
>>
>> Tom Lane:
>> >> This is really what is missing for the ecosystem. A libpqparser for
>> >> tools to use: Formatters, linters, query rewriters, simple syntax
>> >> checkers... they are all
st 15. 5. 2024 v 21:28 odesílatel Tom Lane napsal:
>
> Robert Haas writes:
> > On Wed, May 15, 2024 at 2:39 PM Tom Lane wrote:
> >> The thing that was bothering me most about this is that I don't
> >> understand why that's a useful check. ...
>
> > But I don't understand the idea that the
On Wed, May 15, 2024 at 12:18 PM wrote:
> Tom Lane:
> >> This is really what is missing for the ecosystem. A libpqparser for
> >> tools to use: Formatters, linters, query rewriters, simple syntax
> >> checkers... they are all missing access to postgres' own parser.
> >
> > To get to that, you'd
Robert Haas writes:
> On Wed, May 15, 2024 at 2:39 PM Tom Lane wrote:
>> The thing that was bothering me most about this is that I don't
>> understand why that's a useful check. ...
> But I don't understand the idea that the concept doesn't make sense.
Sorry: "make sense" was a poorly chosen
Tom Lane:
This is really what is missing for the ecosystem. A libpqparser for
tools to use: Formatters, linters, query rewriters, simple syntax
checkers... they are all missing access to postgres' own parser.
To get to that, you'd need some kind of agreement on what the syntax
tree is. I
On Wed, May 15, 2024 at 2:12 PM Josef Šimánek wrote:
> I'm totally OK to mark this as rejected and indeed 45 lines were just
> minimal patch to create PoC (I have coded this during last PGConf.eu
> lunch break) and mainly to start discussion.
Thanks for understanding.
> I'm not sure everyone in
On Wed, May 15, 2024 at 2:39 PM Tom Lane wrote:
> The thing that was bothering me most about this is that I don't
> understand why that's a useful check. If I meant to type
>
> UPDATE mytab SET mycol = 42;
>
> and instead I type
>
> UPDATEE mytab SET mycol = 42;
>
> your proposed
walt...@technowledgy.de writes:
> Tom Lane:
>> BTW, if you do feel that a pure grammar check is worthwhile, you
>> should look at the ecpg preprocessor, which does more or less that
>> with the SQL portions of its input.
> Would working with ecpg allow to get back a parse tree of the query to
>
st 15. 5. 2024 v 20:39 odesílatel Tom Lane napsal:
>
> =?UTF-8?B?Sm9zZWYgxaBpbcOhbmVr?= writes:
> > I'm not sure everyone in this thread understands the reason for this
> > patch, which is clearly my fault, since I have failed to explain. Main
> > idea is to make a tool to validate query can be
Tom Lane:
The thing that was bothering me most about this is that I don't
understand why that's a useful check. If I meant to type
UPDATE mytab SET mycol = 42;
and instead I type
UPDATEE mytab SET mycol = 42;
your proposed feature would catch that; great. But if I type
=?UTF-8?B?Sm9zZWYgxaBpbcOhbmVr?= writes:
> I'm not sure everyone in this thread understands the reason for this
> patch, which is clearly my fault, since I have failed to explain. Main
> idea is to make a tool to validate query can be parsed, that's all.
> Similar to running "EXPLAIN query", but
pá 15. 12. 2023 v 15:50 odesílatel Tom Lane napsal:
>
> Laurenz Albe writes:
> > On Fri, 2023-12-15 at 13:21 +0100, Josef Šimánek wrote:
> >> Inspired by Simon Riggs' keynote talk at PGCounf.eu 2023 sharing list
> >> of ideas for PostgreSQL
> >>
st 15. 5. 2024 v 19:43 odesílatel Robert Haas napsal:
>
> On Sun, Feb 25, 2024 at 5:24 PM Tomas Vondra
> wrote:
> > I think there's about 0% chance we'd add this to "postgres" binary.
>
> Several people have taken this position, so I'm going to mark
> https://commitfest.postgresql.org/48/4704/
On Sun, Feb 25, 2024 at 5:24 PM Tomas Vondra
wrote:
> I think there's about 0% chance we'd add this to "postgres" binary.
Several people have taken this position, so I'm going to mark
https://commitfest.postgresql.org/48/4704/ as Rejected.
My own opinion is that syntax checking is a useful
po 26. 2. 2024 v 8:20 odesílatel Jelte Fennema-Nio napsal:
>
> On Sun, 25 Feb 2024 at 23:34, Josef Šimánek wrote:
> > Exposing parser to frontend tools makes no sense to me
>
> Not everyone seems to agree with that, it's actually already done by
> Lukas from pganalyze:
On Sun, 25 Feb 2024 at 23:34, Josef Šimánek wrote:
> Exposing parser to frontend tools makes no sense to me
Not everyone seems to agree with that, it's actually already done by
Lukas from pganalyze: https://github.com/pganalyze/libpg_query
ne 25. 2. 2024 v 23:24 odesílatel Tomas Vondra
napsal:
>
>
>
> On 12/15/23 16:38, Josef Šimánek wrote:
> > pá 15. 12. 2023 v 16:32 odesílatel David G. Johnston
> > napsal:
> >>
> >> On Fri, Dec 15, 2023 at 8:20 AM Josef Šimánek
> >> wrote:
> >>>
> >>> (parser is not available
> >>> in public
On 12/15/23 16:38, Josef Šimánek wrote:
> pá 15. 12. 2023 v 16:32 odesílatel David G. Johnston
> napsal:
>>
>> On Fri, Dec 15, 2023 at 8:20 AM Josef Šimánek
>> wrote:
>>>
>>> (parser is not available
>>> in public APIs of postgres_fe.h or libpq).
>>
>>
>> What about building "libpg" that
pá 15. 12. 2023 v 16:32 odesílatel David G. Johnston
napsal:
>
> On Fri, Dec 15, 2023 at 8:20 AM Josef Šimánek wrote:
>>
>> (parser is not available
>> in public APIs of postgres_fe.h or libpq).
>
>
> What about building "libpg" that does expose and exports some public APIs for
> the parser?
On Fri, Dec 15, 2023 at 8:20 AM Josef Šimánek
wrote:
> (parser is not available
> in public APIs of postgres_fe.h or libpq).
>
What about building "libpg" that does expose and exports some public APIs
for the parser? We can include a reference CLI implementation for basic
usage of the
pá 15. 12. 2023 v 16:16 odesílatel David G. Johnston
napsal:
>
> On Fri, Dec 15, 2023 at 8:05 AM Josef Šimánek wrote:
>>
>> pá 15. 12. 2023 v 15:50 odesílatel Tom Lane napsal:
>> >
>> > Laurenz Albe writes:
>> > > On Fri, 2023-12-15 at 13:21 +0100, Josef Šimánek wrote:
>> > >> Inspired by
On Fri, Dec 15, 2023 at 8:05 AM Josef Šimánek
wrote:
> pá 15. 12. 2023 v 15:50 odesílatel Tom Lane napsal:
> >
> > Laurenz Albe writes:
> > > On Fri, 2023-12-15 at 13:21 +0100, Josef Šimánek wrote:
> > >> Inspired by Simon Riggs' keynote talk at PGCounf.eu 2023 sharing list
> > >> of ideas for
pá 15. 12. 2023 v 15:50 odesílatel Tom Lane napsal:
>
> Laurenz Albe writes:
> > On Fri, 2023-12-15 at 13:21 +0100, Josef Šimánek wrote:
> >> Inspired by Simon Riggs' keynote talk at PGCounf.eu 2023 sharing list
> >> of ideas for PostgreSQL
> >>
Laurenz Albe writes:
> On Fri, 2023-12-15 at 13:21 +0100, Josef Šimánek wrote:
>> Inspired by Simon Riggs' keynote talk at PGCounf.eu 2023 sharing list
>> of ideas for PostgreSQL
>> (https://riggs.business/blog/f/postgresql-todo-2023), I have crafted a
>> quick patch to do SQL syntax validation.
Dne pá 15. 12. 2023 14:14 uživatel Josef Šimánek
napsal:
>
>
> Dne pá 15. 12. 2023 14:09 uživatel Laurenz Albe
> napsal:
>
>> On Fri, 2023-12-15 at 13:21 +0100, Josef Šimánek wrote:
>> > Inspired by Simon Riggs' keynote talk at PGCounf.eu 2023 sharing list
>> > of ideas for PostgreSQL
>> >
Dne pá 15. 12. 2023 14:09 uživatel Laurenz Albe
napsal:
> On Fri, 2023-12-15 at 13:21 +0100, Josef Šimánek wrote:
> > Inspired by Simon Riggs' keynote talk at PGCounf.eu 2023 sharing list
> > of ideas for PostgreSQL
> > (https://riggs.business/blog/f/postgresql-todo-2023), I have crafted a
> >
On Fri, 2023-12-15 at 13:21 +0100, Josef Šimánek wrote:
> Inspired by Simon Riggs' keynote talk at PGCounf.eu 2023 sharing list
> of ideas for PostgreSQL
> (https://riggs.business/blog/f/postgresql-todo-2023), I have crafted a
> quick patch to do SQL syntax validation.
>
> What do you think?
I
Hello!
Inspired by Simon Riggs' keynote talk at PGCounf.eu 2023 sharing list
of ideas for PostgreSQL
(https://riggs.business/blog/f/postgresql-todo-2023), I have crafted a
quick patch to do SQL syntax validation.
It is also heavily inspired by the "ruby -c" command, useful to check
syntax of
35 matches
Mail list logo
