On 2015/02/18 8:13, Tom Lane wrote:
> So I went back to your v1 patch and have now committed that with some
> cosmetic modifications. Sorry for making you put time into a dead end.
I don't mind it. Thanks for committing the patch!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing
Etsuro Fujita writes:
> On 2015/02/10 14:49, Etsuro Fujita wrote:
>> On 2015/02/07 1:09, Tom Lane wrote:
>>> I think your basic idea of preserving the original parent table's relid
>>> is correct; but instead of doing it like this patch does, I'd be inclined
>>> to make ModifyTable inherit from Sc
On 2015/02/10 14:49, Etsuro Fujita wrote:
> On 2015/02/07 1:09, Tom Lane wrote:
>> IIRC, this code was written at a time when we didn't have NO INHERIT check
>> constraints and so it was impossible for the parent table to get optimized
>> away while leaving children. So the comment in ExplainModif
On 2015/02/07 1:09, Tom Lane wrote:
> IIRC, this code was written at a time when we didn't have NO INHERIT check
> constraints and so it was impossible for the parent table to get optimized
> away while leaving children. So the comment in ExplainModifyTarget was
> good at the time. But it no long
Etsuro Fujita writes:
> On 2015/02/03 15:32, Ashutosh Bapat wrote:
>> Instead, can we show all the relations that are being modified e.g
>> Update on child1, child2, child3. That will disambiguate everything.
> That's an idea, but my concern about that is the cases where there are a
> large numb
Well let's see what others think. Also, we might want to separate that
information on result relations heading probably.
On Fri, Feb 6, 2015 at 1:35 PM, Etsuro Fujita
wrote:
> Hi Ashutosh,
>
> Thank you for the review!
>
>
> On 2015/02/03 15:32, Ashutosh Bapat wrote:
>
>> I agree that it's a pro
Hi Ashutosh,
Thank you for the review!
On 2015/02/03 15:32, Ashutosh Bapat wrote:
I agree that it's a problem, and it looks more severe when there are
multiple children
postgres=# create table parent (a int check (a < 0) no inherit);
CREATE TABLE
postgres=# create table child1 (a int check (a >
Hi Fujita-san,
I agree that it's a problem, and it looks more severe when there are
multiple children
postgres=# create table parent (a int check (a < 0) no inherit);
CREATE TABLE
postgres=# create table child1 (a int check (a >= 0));
CREATE TABLE
postgres=# create table child2 (a int check (a >= 0
On 2015/01/27 9:15, Jim Nasby wrote:
On 12/22/14 12:50 AM, Etsuro Fujita wrote:
I think ExplainModifyTarget should show the parent of the inheritance
tree in multi-target-table cases, as described there, but noticed that
it doesn't always work like that. Here is an example.
Anything ever happ
On 12/22/14 12:50 AM, Etsuro Fujita wrote:
I think ExplainModifyTarget should show the parent of the inheritance
tree in multi-target-table cases, as described there, but noticed that
it doesn't always work like that. Here is an example.
Anything ever happen with this?
--
Jim Nasby, Data Archi
Hi,
I think ExplainModifyTarget should show the parent of the inheritance
tree in multi-target-table cases, as described there, but noticed that
it doesn't always work like that. Here is an example.
postgres=# create table parent (a int check (a < 0) no inherit);
CREATE TABLE
postgres=# create t
11 matches
Mail list logo
