On Sat, Oct 12, 2019 at 03:08:41PM +0900, Michael Paquier wrote:
> On Fri, Oct 11, 2019 at 06:39:47PM -0300, Alvaro Herrera wrote:
>> Typo "resursing". This comment seems a bit too long to me. Maybe
>> "Recursion having ended, drop everything that was collected." suffices.
>> (Fits in one line.)
On Fri, Oct 11, 2019 at 06:39:47PM -0300, Alvaro Herrera wrote:
> Typo "resursing". This comment seems a bit too long to me. Maybe
> "Recursion having ended, drop everything that was collected." suffices.
> (Fits in one line.)
Sounds fine to me, thanks.
--
Michael
signature.asc
Description: PG
On 2019-Oct-11, Michael Paquier wrote:
> + if (!recursing)
> + {
> + /*
> + * The resursing lookup for inherited child relations is done.
> All
> + * the child relations have been scanned and the object
> addresses of
> + * all the colu
On Fri, Oct 11, 2019 at 04:23:51PM +0900, Amit Langote wrote:
> Thanks. The index on b is not really necessary for testing because it
> remains unaffected, but maybe it's fine.
That's on purpose. Any more comments?
--
Michael
signature.asc
Description: PGP signature
On Fri, Oct 11, 2019 at 4:16 PM Michael Paquier wrote:
> On Thu, Oct 10, 2019 at 05:28:02PM +0900, Amit Langote wrote:
> > Actually, the code initializes it on the first call (recursing is
> > false) and asserts that it must have been already initialized in a
> > recursive (recursing is true) call
On Thu, Oct 10, 2019 at 05:28:02PM +0900, Amit Langote wrote:
> Actually, the code initializes it on the first call (recursing is
> false) and asserts that it must have been already initialized in a
> recursive (recursing is true) call.
I have actually kept your simplified version.
> Okay, sure.
On Thu, Oct 10, 2019 at 4:53 PM Michael Paquier wrote:
> On Thu, Oct 10, 2019 at 02:56:32PM +0900, Amit Langote wrote:
> > /* Initialize addrs on the first invocation. */
>
> I would add "recursive" here, to give:
> /* Initialize addrs on the first recursive invocation. */
Actually, the code init
On Thu, Oct 10, 2019 at 02:56:32PM +0900, Amit Langote wrote:
> /*
> * Drops column 'colName' from relation 'rel' and returns the address of the
> * dropped column. The column is also dropped (or marked as no longer
> * inherited from relation) from the relation's inheritance children, if any.
Hello,
On Thu, Oct 10, 2019 at 1:13 PM Michael Paquier wrote:
> On Wed, Oct 09, 2019 at 06:36:35AM -0300, Alvaro Herrera wrote:
> > Right, something like that. Needs a comment to explain what we do and
> > how recursing=true correlates with addrs=NULL, I think. Maybe add an
> > assert.
>
> Yes,
On Wed, Oct 09, 2019 at 06:36:35AM -0300, Alvaro Herrera wrote:
> Right, something like that. Needs a comment to explain what we do and
> how recursing=true correlates with addrs=NULL, I think. Maybe add an
> assert.
Yes, that would be a thing to do. So I have added more comments
regarding that
On 2019-Oct-09, Michael Paquier wrote:
> On Tue, Oct 08, 2019 at 06:25:05PM +0900, Amit Langote wrote:
> > I thought about doing something like that, but wasn't sure if
> > introducing that much complexity is warranted.
>
> I looked at that. By experience, I think that it would be wiser to do
>
On Tue, Oct 08, 2019 at 06:25:05PM +0900, Amit Langote wrote:
> I thought about doing something like that, but wasn't sure if
> introducing that much complexity is warranted.
I looked at that. By experience, I think that it would be wiser to do
first the lookup of all the dependencies you would l
On Tue, Oct 8, 2019 at 2:12 PM Amit Langote wrote:
>
> Hi Ashutosh,
>
> On Mon, Oct 7, 2019 at 1:39 PM Ashutosh Sharma wrote:
> > I think we could have first deleted all the dependency of child object
> > on parent and then deleted the child itself using performDeletion().
>
> So, there are two o
On Tue, Oct 8, 2019 at 6:15 PM Alvaro Herrera wrote:
> Apologies for not helping much here; I'm on vacation for a couple of
> weeks.
No worries, please take your time.
> On 2019-Oct-08, Amit Langote wrote:
>
> > I couldn't imagine how that trick could be implemented for this case. :(
>
> Can't w
Apologies for not helping much here; I'm on vacation for a couple of
weeks.
On 2019-Oct-08, Amit Langote wrote:
> I couldn't imagine how that trick could be implemented for this case. :(
Can't we pass around an ObjectAddresses pointer to which each recursion
level adds the object(s) it wants to
Hi Ashutosh,
On Mon, Oct 7, 2019 at 1:39 PM Ashutosh Sharma wrote:
> I think we could have first deleted all the dependency of child object
> on parent and then deleted the child itself using performDeletion().
So, there are two objects to consider in this case -- column and an
index that depend
I think we could have first deleted all the dependency of child object
on parent and then deleted the child itself using performDeletion().
As an example let's consider the case of toast table where we first
delete the dependency of toast relation on main relation and then
delete the toast table it
Hello,
On Fri, Oct 4, 2019 at 5:57 PM Michael Paquier wrote:
>
> On Thu, Oct 03, 2019 at 09:18:12AM -0300, Alvaro Herrera wrote:
> > Hmm. I wonder if we shouldn't adopt the coding pattern we've used
> > elsewhere of collecting all columns to be dropped first into an
> > ObjectAddresses array, th
On Thu, Oct 03, 2019 at 09:18:12AM -0300, Alvaro Herrera wrote:
> Hmm. I wonder if we shouldn't adopt the coding pattern we've used
> elsewhere of collecting all columns to be dropped first into an
> ObjectAddresses array, then use performMultipleDeletions.
+1. That's the common pattern these da
On 2019-Oct-03, Amit Langote wrote:
> There may not really be any problem with the commit itself, but I
> suspect that the new types of dependencies (or the way
> findDependentObject() analyzes them) don't play well with inheritance
> recursion of ATExecDropColumn(). Currently, child columns (and
On Wed, Sep 4, 2019 at 2:36 PM Amit Langote wrote:
>
> Hi,
>
> Maybe I'm forgetting some dependency management discussion that I was
> part of recently, but is the following behavior unintentional?
>
> create table p (a int, b int, c int) partition by list (a);
> create table p1 partition of p for
21 matches
Mail list logo
