On Thu, Feb 07, 2019 at 12:11:49PM -0300, Alvaro Herrera wrote:
> I looked at it briefly a few weeks ago and it seemed sound, though I
> haven't yet tried to write the constraint display query for psql using
> it, yet -- but that should be straightforward anyway. Let's get it
> committed so we hav
On 2019-Feb-07, Michael Paquier wrote:
> On Thu, Feb 07, 2019 at 01:34:15PM +0900, Amit Langote wrote:
> > Yeah, I agree. Should also check with Alvaro maybe?
>
> Good idea. Let's wait for his input.
I looked at it briefly a few weeks ago and it seemed sound, though I
haven't yet tried to writ
On Thu, Feb 07, 2019 at 01:34:15PM +0900, Amit Langote wrote:
> Yeah, I agree. Should also check with Alvaro maybe?
Good idea. Let's wait for his input.
--
Michael
signature.asc
Description: PGP signature
Hi,
On 2019/02/06 19:14, Michael Paquier wrote:
>> Given that a couple (?) of other patches depend on this, maybe it'd be a
>> good idea to proceed with this.
>
> If you are happy with the version attached, I am fine to commit it. I
> think that we have the right semantics and the right test cov
On Wed, Feb 06, 2019 at 05:26:48PM +0900, Amit Langote wrote:
> Some minor comments on v4:
Thanks for the review.
> +/*
> + * Perform several checks on a relation on which is extracted some
> + * information related to its partition tree.
>
> This is a bit unclear to me. How about:
>
> Checks
Hi Michael,
Sorry about the long delay in replying. Looking at the latest patch (v4)
but replying to an earlier email of yours.
On 2018/12/15 10:16, Michael Paquier wrote:
> On Fri, Dec 14, 2018 at 02:20:27PM +0900, Amit Langote wrote:
>> +static bool
>> +check_rel_for_partition_info(Oid relid)
On Sat, Dec 15, 2018 at 10:16:08AM +0900, Michael Paquier wrote:
> Changed in this sense. Please find attached an updated patch.
Rebased as per the attached, and moved to next CF.
--
Michael
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 4930ec17f6..86ff4e5c9e 100644
--- a/doc
On Fri, Dec 14, 2018 at 02:20:27PM +0900, Amit Langote wrote:
> Given that pg_partition_root will return a valid result for any relation
> that can be part of a partition tree, it seems strange that the above
> sentence says "for the given partitioned table or partitioned index". It
> should perha
Hi,
On 2018/12/12 10:48, Michael Paquier wrote:
> On Fri, Dec 07, 2018 at 11:46:05AM +0900, Michael Paquier wrote:
>> On Thu, Dec 06, 2018 at 10:48:59PM -0300, Alvaro Herrera wrote:
>>> I think adding a pg_partition_root() call to as many pg_partition_tree
>>> tests as you modified is overkill ...
On Fri, Dec 07, 2018 at 11:46:05AM +0900, Michael Paquier wrote:
> On Thu, Dec 06, 2018 at 10:48:59PM -0300, Alvaro Herrera wrote:
>> I think adding a pg_partition_root() call to as many pg_partition_tree
>> tests as you modified is overkill ... OTOH I'd have one test that
>> invokes pg_partition_t
On Thu, Dec 06, 2018 at 10:48:59PM -0300, Alvaro Herrera wrote:
> I think adding a pg_partition_root() call to as many pg_partition_tree
> tests as you modified is overkill ... OTOH I'd have one test that
> invokes pg_partition_tree(pg_partition_root(some-partition)) to verify
> that starting from
I think adding a pg_partition_root() call to as many pg_partition_tree
tests as you modified is overkill ... OTOH I'd have one test that
invokes pg_partition_tree(pg_partition_root(some-partition)) to verify
that starting from any point in the tree you get the whole tree.
I haven't actually tried
Hi all,
Álvaro has given faced a use case where it would be useful to have a
function which is able to return the top-most parent of a partition
tree:
https://postgr.es/m/20181204184159.eue3wlchqrkh4vsc@alvherre.pgsql
This has been mentioned as well on the thread where was discussed
pg_partition_
13 matches
Mail list logo
