On Sun, Mar 17, 2024 at 01:51:39PM +0100, Peter Eisentraut wrote:
> I have committed this patch series. Thanks.
My compiler is worried that "newtarget" might be getting used
uninitialized. AFAICT there's no actual risk here, so I think initializing
it to 0 is sufficient. I'll commit the attache
On 14.03.24 15:46, Tomas Vondra wrote:
2) The newtarget handling in AlterStatistics seems rather confusing.
Why
does it get set to -1 just to ignore the value later? For a while I was
99% sure ALTER STATISTICS ... SET STATISTICS DEFAULT will set the field
to -1. Maybe ditching the first if block
On 3/14/24 11:13, Peter Eisentraut wrote:
> On 12.03.24 14:32, Tomas Vondra wrote:
>> On 3/12/24 13:47, Peter Eisentraut wrote:
>>> On 06.03.24 22:34, Tomas Vondra wrote:
0001
1) I think this bit in ALTER STATISTICS docs is wrong:
- >>> class="parameter">n
On 12.03.24 14:32, Tomas Vondra wrote:
On 3/12/24 13:47, Peter Eisentraut wrote:
On 06.03.24 22:34, Tomas Vondra wrote:
0001
1) I think this bit in ALTER STATISTICS docs is wrong:
- new_target
+ SET STATISTICS { integer | DEFAULT }
because it means we now have list entries for
On 3/12/24 13:47, Peter Eisentraut wrote:
> On 06.03.24 22:34, Tomas Vondra wrote:
>> 0001
>>
>>
>> 1) I think this bit in ALTER STATISTICS docs is wrong:
>>
>> - > class="parameter">new_target
>> + SET STATISTICS { > class="parameter">integer | DEFAULT }
>>
>> because it means we
On 06.03.24 22:34, Tomas Vondra wrote:
0001
1) I think this bit in ALTER STATISTICS docs is wrong:
- new_target
+ SET STATISTICS { integer | DEFAULT }
because it means we now have list entries for name, ..., new_name,
new_schema, and then suddenly "SET STATISTICS { integer | DEF
Hi Peter,
I took a look at this patch today. I think it makes sense to do this,
and I haven't found any major issues with any of the three patches. A
couple minor comments:
0001
1) I think this bit in ALTER STATISTICS docs is wrong:
- new_target
+ SET STATISTICS { integer | DEFAU
On 12.01.24 12:16, Alvaro Herrera wrote:
In get_attstattarget() I think we should return 0 for dropped columns
without reading attstattarget, which is useless anyway, and if it did
happen to return non-null, it might cause us to do stuff, which would be
a waste.
I ended up deciding to get rid o
BTW I wanted to but didn't say so explicitly, so here goes: 0001 looks
ready to go in.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
"Find a bug in a program, and fix it, and the program will work today.
Show the program how to find and fix a bug, and the progra
On 2024-Jan-11, Peter Eisentraut wrote:
> On 10.01.24 14:16, Alvaro Herrera wrote:
> > Seems reasonable. Do we really need a catversion bump for this?
>
> Yes, this changes the order of the fields in pg_attribute.
Ah, right.
> > In get_attstattarget() I think we should return 0 for dropped co
3 patch gets rid of it anyway.
From d937c26d8c471c999aa53c96dce86c68fad71a7a Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Thu, 11 Jan 2024 10:09:02 +0100
Subject: [PATCH v3 1/3] Make attstattarget nullable
This changes the pg_attribute field attstattarget into a nullable
field in the var
On 2023-Dec-23, Peter Eisentraut wrote:
> Here is an updated patch rebased over 3e2e0d5ad7.
>
> The 0001 patch stands on its own, but I also tacked on two additional WIP
> patches that simplify some pg_attribute handling and make these kinds of
> refactorings simpler in the future. See descripti
ffc2b-e0e8-77f7-38fb-be921dff71af%40enterprisedb.com
From f370eceec0cbb9b6bf76d3394e56a5df4280c906 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Sat, 23 Dec 2023 10:47:19 +0100
Subject: [PATCH v2 1/3] Make attstattarget nullable
This changes the pg_attribute field attstattarget into a nullabl
-77f7-38fb-be921dff71af%40enterprisedb.com
From 174d51a66c80a3284ad97b347a286a7b65a2a440 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Tue, 5 Dec 2023 13:43:30 +0100
Subject: [PATCH v1] Make attstattarget nullable
This changes the pg_attribute field attstattarget into a nullable
field in the varia
14 matches
Mail list logo
