On Wed, 2020-09-30 at 16:27 +0900, Michael Paquier wrote:
> On Fri, Sep 04, 2020 at 01:59:47PM +0200, Laurenz Albe wrote:
> > I'll set the commitfest entry to "waiting for author".
>
> This review, as well as any of the follow-up emails, have not been
> answered by the author, so I have marked
On Fri, Sep 04, 2020 at 01:59:47PM +0200, Laurenz Albe wrote:
> I'll set the commitfest entry to "waiting for author".
This review, as well as any of the follow-up emails, have not been
answered by the author, so I have marked the patch as returned with
feedback.
--
Michael
signature.asc
On 2020-Sep-08, Laurenz Albe wrote:
> We should at least have
>
> ALTER TABLE ... ADD PRIMARY KEY (id) INCLUDE (val);
>
> or something before we consider this patch.
Agreed.
Now the trick in this new command is to let the user change the included
columns afterwards, which remains useful
On Mon, 2020-09-07 at 11:42 -0300, Alvaro Herrera wrote:
> > This patch would provide a more convenient way to do that.
> > Again, I am not sure if that justifies the effort.
>
> I have to admit I've seen cases where it'd be useful to have included
> columns in primary keys.
>
> TBH I think if
On 2020-Sep-07, Laurenz Albe wrote:
> This patch would provide a more convenient way to do that.
>
> Again, I am not sure if that justifies the effort.
I have to admit I've seen cases where it'd be useful to have included
columns in primary keys.
TBH I think if we really wanted the feature of
On Fri, 2020-09-04 at 13:31 -0400, Alvaro Herrera wrote:
> On 2020-Sep-04, Laurenz Albe wrote:
> > On Fri, 2020-09-04 at 10:41 -0400, Alvaro Herrera wrote:
> > > > The value I see in this is:
> > > > - replacing a primary key index
> > > > - replacing the index behind a constraint targeted by a
On 2020-Sep-04, Laurenz Albe wrote:
> On Fri, 2020-09-04 at 10:41 -0400, Alvaro Herrera wrote:
> > > The value I see in this is:
> > > - replacing a primary key index
> > > - replacing the index behind a constraint targeted by a foreign key
> >
> > But why is this better than using REINDEX
On Fri, 2020-09-04 at 10:41 -0400, Alvaro Herrera wrote:
> > The value I see in this is:
> > - replacing a primary key index
> > - replacing the index behind a constraint targeted by a foreign key
>
> But why is this better than using REINDEX CONCURRENTLY?
It is not better, but it can be used to
On 2020-Sep-04, Laurenz Albe wrote:
> The value I see in this is:
> - replacing a primary key index
> - replacing the index behind a constraint targeted by a foreign key
But why is this better than using REINDEX CONCURRENTLY?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
On Mon, 2020-08-10 at 09:29 +0300, Anna Akenteva wrote:
> On 2020-07-07 01:08, Tom Lane wrote:
>
> > Alvaro Herrera writes:
> > > On 2020-Jul-05, Anna Akenteva wrote:
> > > > -- Swapping primary key's index for an equivalent index,
> > > > -- but with INCLUDE-d attributes.
> > > > CREATE UNIQUE
On 2020-07-07 01:08, Tom Lane wrote:
Alvaro Herrera writes:
On 2020-Jul-05, Anna Akenteva wrote:
-- Swapping primary key's index for an equivalent index,
-- but with INCLUDE-d attributes.
CREATE UNIQUE INDEX new_idx ON target_tbl (id) INCLUDE (info);
ALTER TABLE target_tbl ALTER CONSTRAINT
Alvaro Herrera writes:
> On 2020-Jul-05, Anna Akenteva wrote:
>> -- Swapping primary key's index for an equivalent index,
>> -- but with INCLUDE-d attributes.
>> CREATE UNIQUE INDEX new_idx ON target_tbl (id) INCLUDE (info);
>> ALTER TABLE target_tbl ALTER CONSTRAINT target_tbl_pkey USING INDEX
On 2020-Jul-05, Anna Akenteva wrote:
> -- Swapping primary key's index for an equivalent index,
> -- but with INCLUDE-d attributes.
> CREATE UNIQUE INDEX new_idx ON target_tbl (id) INCLUDE (info);
> ALTER TABLE target_tbl ALTER CONSTRAINT target_tbl_pkey USING INDEX
> new_idx;
> ALTER TABLE
13 matches
Mail list logo
