Re: Parser Hook

From: Joshua Drake <jd(at)commandprompt(dot)com>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Jim Mlodgenski <jimmy76(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Parser Hook
Date: 2021-03-15 18:39:55
Message-ID: CAJvJg-S3=h39ojFaaaX8UH+iREi-ZR3fvXMUvBM=ynpe1VXSUg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
>
>
> Also, I'm not sure that many extensions would really benefit from custom
> utility command, as you can already do pretty much anything you want using
> SQL
> functions. For instance it would be nice for hypopg to be able to support
>
> CREATE HYPOTHETICAL INDEX ...
>
> rather than
>
> SELECT hypopg_create_index('CREATE INDEX...')
>
> But really the only benefit would be autocompletion, which still wouldn't
> be
> possible as psql autocompletion won't be extended. And even if it somehow
> was,
> I wouldn't expect all psql clients to be setup as needed.
>

"technically" speaking you are correct, usability speaking you are not. We
ran into this discussion previously when dealing with replication. There is
certainly a history to calling functions to do what the grammar (from a
usability perspective) should do and that is not really a good history. It
is just what we are all used to. Looking at what you wrote above as a DBA
or even an average developer: CREATE HYPOTHETICAL INDEX makes much more
sense than the SELECT execution.

JD

P.S. I had to write HYPOTHETICAL 4 times, I kept typing HYPOTECHNICAL :/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-03-15 18:49:51 Re: Tightening up allowed custom GUC names
Previous Message Mark Dilger 2021-03-15 18:38:35 Re: pg_amcheck contrib application