>
>
>
> 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
>
> SELE
> > the
> > > query twice plus deparsing it will probably make that approach way too
> > > expensive in many usecases, so we shouldn't go that way.
> > >
> >
> > yes - so it can be nice to have more possibilities.
> >
> > parsing is ex
> yes - so it can be nice to have more possibilities.
>
> parsing is expensive - but on today computers, the cost of parsing is low -
> the optimization is significantly more expensive.
>
> I wrote some patches in this area (all rejected by Tom :)), and a lot of
> work can be
rote some patches in this area (all rejected by Tom :)), and a lot of
work can be done after parser and before the analysis stage. Probably, the
parser hook is not good enough, there should be an analysis stage hook too.
On Mon, Mar 15, 2021 at 06:05:52PM +0100, Pavel Stehule wrote:
>
> Possibility to work with a parser is one main reason for forking postgres.
> Lot of interestings projects fail on the cost of maintaining their own fork.
>
> Maybe a good enough possibility is the possibility to inject an own pars
> 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 hyp
On Mon, Mar 15, 2021 at 12:58 PM Joel Jacobson wrote:
> On Mon, Mar 15, 2021, at 16:48, Jim Mlodgenski wrote:
>
> The example I have is adding a CREATE JOB command that a scheduler may
> use.
>
>
> This CREATE JOB thing sounds interesting.
>
> Are you working on adding the ability to schedule SQL
eeded for an extension maintainer doesn't appear to be that
> > onerous. Its not ideal having to copy and patch gram.y, but certainly
> > doable for someone wanting to extend the parser.
>
> AFAIK nothing in bison prevents you from silently ignoring unhandled
> grammar
>
On Mon, Mar 15, 2021, at 16:48, Jim Mlodgenski wrote:
> The example I have is adding a CREATE JOB command that a scheduler may use.
This CREATE JOB thing sounds interesting.
Are you working on adding the ability to schedule SQL-commands to run in the
background,
similar to cronjob and/or adding
py and patch gram.y, but certainly
> doable for someone wanting to extend the parser.
AFAIK nothing in bison prevents you from silently ignoring unhandled grammar
rather than erroring out. So you could have a parser hook called first, and
if no valid command was recognized fall back on the origina
On Mon, Feb 22, 2021 at 3:52 PM Andres Freund wrote:
> Hi,
>
> On 2021-02-22 11:20:54 -0500, Jim Mlodgenski wrote:
> > As Jan mentioned in his thread about a pluggable wire protocol [0], AWS
> is
> > working on a set of extensions for Babelfish. The intention is to not
> > necessarily have it as
Hi,
On 2021-02-22 11:20:54 -0500, Jim Mlodgenski wrote:
> As Jan mentioned in his thread about a pluggable wire protocol [0], AWS is
> working on a set of extensions for Babelfish. The intention is to not
> necessarily have it as a single monolithic extension, but be possible for
> people to use p
As Jan mentioned in his thread about a pluggable wire protocol [0], AWS is
working on a set of extensions for Babelfish. The intention is to not
necessarily have it as a single monolithic extension, but be possible for
people to use pieces of it as they need when they are migrating to
PostgreSQL. S
13 matches
Mail list logo
