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 fujita.ets...@lab.ntt.co.jp 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
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
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 longer
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 =
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 fujita.ets...@lab.ntt.co.jp
wrote:
Hi Ashutosh,
Thank you for the review!
On 2015/02/03 15:32, Ashutosh Bapat wrote:
I
Etsuro Fujita fujita.ets...@lab.ntt.co.jp 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
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 =
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
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
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
11 matches
Mail list logo
