On 2020-05-06 16:37, Peter Eisentraut wrote:
On 2020-04-22 16:26, Peter Eisentraut wrote:
On 2020-04-22 01:56, Alvaro Herrera wrote:
I'm surprised that this hasn't applied yet, because:
On 2020-Apr-09, Peter Eisentraut wrote:
One thing to remember is that the current situation is broken.
On 2020-04-22 16:26, Peter Eisentraut wrote:
On 2020-04-22 01:56, Alvaro Herrera wrote:
I'm surprised that this hasn't applied yet, because:
On 2020-Apr-09, Peter Eisentraut wrote:
One thing to remember is that the current situation is broken. While you
can set index columns to have
On 2020-04-22 01:56, Alvaro Herrera wrote:
I'm surprised that this hasn't applied yet, because:
On 2020-Apr-09, Peter Eisentraut wrote:
One thing to remember is that the current situation is broken. While you
can set index columns to have different storage than the corresponding table
I'm surprised that this hasn't applied yet, because:
On 2020-Apr-09, Peter Eisentraut wrote:
> One thing to remember is that the current situation is broken. While you
> can set index columns to have different storage than the corresponding table
> columns, pg_dump does not preserve that,
On 2020-03-30 18:17, Alvaro Herrera wrote:
On 2020-Feb-25, Peter Eisentraut wrote:
An alternative would be that we make this situation fully supported. Then
we'd probably need at least ALTER INDEX ... ALTER COLUMN ... SET STORAGE,
and some pg_dump support.
I think this is a more promising
> ALTER TABLE ... SET STORAGE does not propagate to indexes, even though
> indexes created afterwards get the new storage setting. So depending on
> the order of commands, you can get inconsistent storage settings between
> indexes and tables.
I've absolutely noticed this beha
On 2020-Feb-25, Peter Eisentraut wrote:
> An alternative would be that we make this situation fully supported. Then
> we'd probably need at least ALTER INDEX ... ALTER COLUMN ... SET STORAGE,
> and some pg_dump support.
I think this is a more promising direction.
--
Álvaro Herrera
On Tue, Feb 25, 2020 at 1:09 PM Peter Eisentraut
wrote:
>
> On 2020-02-24 12:21, Kuntal Ghosh wrote:
> > I've reproduced the issue on head. And, the patch seems to solve the
> > problem. The patch looks good to me. But, I've a small doubt regarding
> > the changes in test_decoding regression
On 2020-02-24 12:21, Kuntal Ghosh wrote:
I've reproduced the issue on head. And, the patch seems to solve the
problem. The patch looks good to me. But, I've a small doubt regarding
the changes in test_decoding regression file.
diff --git a/contrib/test_decoding/sql/toast.sql
Hello Peter,
On Mon, Feb 24, 2020 at 12:59 PM Peter Eisentraut
wrote:
>
> On 2020-01-06 13:32, Peter Eisentraut wrote:
> > Attached is a patch that attempts to fix this by propagating the storage
> > change to existing indexes. This triggers a few regression test
> > failures (going from no
On 2020-01-06 13:32, Peter Eisentraut wrote:
Attached is a patch that attempts to fix this by propagating the storage
change to existing indexes. This triggers a few regression test
failures (going from no error to error), which I attempted to fix up,
but I haven't analyzed what the tests were
ALTER TABLE ... SET STORAGE does not propagate to indexes, even though
indexes created afterwards get the new storage setting. So depending on
the order of commands, you can get inconsistent storage settings between
indexes and tables. For example:
create table foo1 (a text);
alter table
12 matches
Mail list logo
