On 2022-Jul-26, Michael Paquier wrote:
> On Mon, Jul 25, 2022 at 12:55:54PM +0200, Alvaro Herrera wrote:
> > Agreed. I think you already have the query for that elsewhere in the
> > test, so it's just a matter of copying it from there.
>
> I actually already wrote most of it in 2cbc3c1, and I ju
On Mon, Jul 25, 2022 at 12:55:54PM +0200, Alvaro Herrera wrote:
> Agreed. I think you already have the query for that elsewhere in the
> test, so it's just a matter of copying it from there.
I actually already wrote most of it in 2cbc3c1, and I just needed to
extend things a bit to detect the OID
On 2022-Jul-25, Michael Paquier wrote:
> On Mon, Jul 25, 2022 at 11:49:50AM +0200, Alvaro Herrera wrote:
> > On 2022-Jul-23, Michael Paquier wrote:
> >> By the way, it seems that 83011ce also broke the case of "REINDEX
> >> DATABASE CONCURRENTLY", where the parser missed the addition of a
> >> De
On Mon, Jul 25, 2022 at 11:49:50AM +0200, Alvaro Herrera wrote:
> On 2022-Jul-23, Michael Paquier wrote:
>> As the problem comes down to the fact that INDEX/TABLE, SCHEMA and
>> DATABASE/SYSTEM need to handle names for different object types each,
>> I think that we could do something like the atta
On 2022-Jul-23, Michael Paquier wrote:
> As the problem comes down to the fact that INDEX/TABLE, SCHEMA and
> DATABASE/SYSTEM need to handle names for different object types each,
> I think that we could do something like the attached, removing one
> block on the way at the cost of an extra parser
On Fri, Jul 22, 2022 at 11:54:27PM -0400, Tom Lane wrote:
> That does not seem like an improvement. In v15:
>
> regression=# REINDEX SYSTEM CONCURRENTLY db;
> ERROR: cannot reindex system catalogs concurrently
>
> As of HEAD:
>
> regression=# REINDEX SYSTEM CONCURRENTLY db;
> ERROR: syntax er
Michael Paquier writes:
> I have just looked at 83011ce, and got what you've done here. You
> have thrown away reindex_target_multitable and added three parts for
> SCHEMA, DATABASE and SYSTEM instead with their own options, enforcing
> the restriction on CONCURRENTLY at the end of REINDEX SYSTEM
On Fri, Jul 22, 2022 at 03:06:46PM +0200, Alvaro Herrera wrote:
> Actually, looking at the grammar again I realized that the '('options')'
> part could be refactored; and with that, keeping an extra production for
> REINDEX DATABASE CONCURRENTLY is short enough. It is removed from
> REINDEX SYSTEM
On 2022-Jul-22, Michael Paquier wrote:
> So this indeed has as effect to make possible the use of CONCURRENTLY
> for DATABASE and SYSTEM only within the parenthesized grammar. Seeing
> the simplifications this creates, I'd agree with dropping this part of
> the grammar.
Actually, looking at the
On Thu, Jul 21, 2022 at 07:42:12PM +0200, Alvaro Herrera wrote:
> Thanks. I was looking at the recently modified REINDEX syntax and
> noticed there another spot for taking an optional name. I ended up
> reusing OptSchemaName for that, as in the attached patch. I think
> adding production-specifi
On Thu, 21 Jul 2022 at 18:42, Alvaro Herrera wrote:
>
> Thanks. I was looking at the recently modified REINDEX syntax and
> noticed there another spot for taking an optional name. I ended up
> reusing OptSchemaName for that, as in the attached patch. I think
> adding production-specific additio
On 2022-Jul-21, Dean Rasheed wrote:
> I tend to agree with Matthias' earlier point about avoiding code
> duplication in the grammar. Without going off and refactoring other
> parts of the grammar not related to this patch, it's still a slightly
> smaller, simpler change, and less code duplication,
On 7/21/22 16:12, Dean Rasheed wrote:
> On Wed, 20 Jul 2022 at 12:01, Matthias van de Meent
> wrote:
>>
>> On Wed, 13 Jul 2022 at 08:07, Simon Riggs
>> wrote:
>>>
+ *CREATE STATISTICS [ [IF NOT EXISTS] stats_name ]
>>
>> I think this is ready for a committer, so I've marked
On Thu, 21 Jul 2022 at 15:12, Dean Rasheed wrote:
>
> On Wed, 20 Jul 2022 at 12:01, Matthias van de Meent
> wrote:
> >
> > On Wed, 13 Jul 2022 at 08:07, Simon Riggs
> > wrote:
> > >
> > > > + *CREATE STATISTICS [ [IF NOT EXISTS] stats_name ]
> >
> > I think this is ready for a c
On Wed, 20 Jul 2022 at 12:01, Matthias van de Meent
wrote:
>
> On Wed, 13 Jul 2022 at 08:07, Simon Riggs
> wrote:
> >
> > > + *CREATE STATISTICS [ [IF NOT EXISTS] stats_name ]
>
> I think this is ready for a committer, so I've marked it as such.
>
Picking this up...
I tend to a
On Wed, 13 Jul 2022 at 08:07, Simon Riggs wrote:
>
> On Thu, 7 Jul 2022 at 11:58, Matthias van de Meent
> wrote:
> > A more correct version would be
> >
> > + *CREATE STATISTICS [ [IF NOT EXISTS] stats_name ]
> > [(stat types)]
>
> There you go
Thanks!
I think this is ready for
On Thu, 7 Jul 2022 at 11:58, Matthias van de Meent
wrote:
>
> On Thu, 7 Jul 2022 at 12:55, Simon Riggs wrote:
> > There are various other ways of doing this and, yes, we could refactor
> > other parts of the grammar to make this work. There is a specific
> > guideline about patch submission that
On Thu, 7 Jul 2022 at 12:55, Simon Riggs wrote:
> There are various other ways of doing this and, yes, we could refactor
> other parts of the grammar to make this work. There is a specific
> guideline about patch submission that says the best way to get a patch
> rejected is to include unnecessary
On Wed, 6 Jul 2022 at 19:35, Matthias van de Meent
wrote:
>
> On Sun, 15 May 2022 at 14:20, Simon Riggs
> wrote:
> >
> > Currently, CREATE STATS requires you to think of a name for each stats
> > object, which is fairly painful, so users would prefer an
> > automatically assigned name.
> >
> > A
On Sun, 15 May 2022 at 14:20, Simon Riggs wrote:
>
> Currently, CREATE STATS requires you to think of a name for each stats
> object, which is fairly painful, so users would prefer an
> automatically assigned name.
>
> Attached patch allows this, which turns out to be very simple, since a
> name a
ne 15. 5. 2022 v 14:20 odesÃlatel Simon Riggs
napsal:
> Currently, CREATE STATS requires you to think of a name for each stats
> object, which is fairly painful, so users would prefer an
> automatically assigned name.
>
> Attached patch allows this, which turns out to be very simple, since a
> na
Currently, CREATE STATS requires you to think of a name for each stats
object, which is fairly painful, so users would prefer an
automatically assigned name.
Attached patch allows this, which turns out to be very simple, since a
name assignment function already exists.
The generated name is simpl
22 matches
Mail list logo
