On Mon, Mar 04, 2019 at 03:56:00PM -0300, Alvaro Herrera wrote:
> I added tests to immortalize the current behavior for legacy inheritance
> relations too. Thanks!
Makes sense, thanks.
--
Michael
signature.asc
Description: PGP signature
On 2019-Feb-28, Alvaro Herrera wrote:
> What about legacy inheritance? I see that pg_partition_tree handles
> that case perfectly well -- it seems to return the complete hierarchy
> rooted at the given relation. However, it seems odd that it works at
> all, don't you think? Consider this:
> [..
On Mon, Mar 04, 2019 at 10:44:10AM +0900, Amit Langote wrote:
> Thanks for committing and adding me as an author.
Sure. A good portion of the changes suggested on the backend was
mainly yours, so that looked right to me.
--
Michael
signature.asc
Description: PGP signature
On 2019/03/02 18:21, Michael Paquier wrote:
> On Fri, Mar 01, 2019 at 11:38:20AM -0500, Tom Lane wrote:
>> Right, while you'd get zero rows out for a non-partitioned table.
>> WFM.
>
> Exactly. I have committed a patch doing exactly that, and I have
> added test cases with a partitioned table and
On Fri, Mar 01, 2019 at 11:38:20AM -0500, Tom Lane wrote:
> Right, while you'd get zero rows out for a non-partitioned table.
> WFM.
Exactly. I have committed a patch doing exactly that, and I have
added test cases with a partitioned table and a partitioned index
which have no partitions.
--
Mic
Michael Paquier writes:
> On Thu, Feb 28, 2019 at 11:50:16PM -0500, Tom Lane wrote:
>> But, having said that, we've learned that it's generally bad for
>> catalog-query functions to fail outright just because they're pointed
>> at the wrong kind of catalog object. So I think that what we want her
On Thu, Feb 28, 2019 at 11:50:16PM -0500, Tom Lane wrote:
> FWIW, I don't agree with Michael's suggestion above. A plain table is
> significantly different from a partitioned table with no children:
> you can store rows in the former but not the latter, and you can add
> partitions to the latter b
Amit Langote writes:
> On 2019/03/01 9:22, Michael Paquier wrote:
>> What I am writing next sounds perhaps a bit fancy, but in my opinion a
>> normal table is itself a partition tree, made of one single member:
>> itself.
> That's what we discussed, but it seems that we ended up allowing regular
Hi,
On 2019/03/01 9:22, Michael Paquier wrote:
> On Thu, Feb 28, 2019 at 04:32:03PM -0300, Alvaro Herrera wrote:
>> Yeah, looks good, please push.
>
> Done for this part.
>
>> I would opt for returning the empty set for legacy inheritance too.
>>
>> More generally, I think we should return empty
On Thu, Feb 28, 2019 at 04:32:03PM -0300, Alvaro Herrera wrote:
> Yeah, looks good, please push.
Done for this part.
> I would opt for returning the empty set for legacy inheritance too.
>
> More generally, I think we should return empty for anything that's
> either not RELKIND_PARTITIONED_TABLE
On 2019-Feb-28, Michael Paquier wrote:
> On Wed, Feb 27, 2019 at 03:48:08PM -0300, Alvaro Herrera wrote:
> > I just happened to come across the result of this rationale in
> > pg_partition_tree() (an SRF) while developing a new related function,
> > pg_partition_ancestors(), and find the resulting
Hi,
On 2019/02/28 10:45, Michael Paquier wrote:
> On Wed, Feb 27, 2019 at 03:48:08PM -0300, Alvaro Herrera wrote:
>> I just happened to come across the result of this rationale in
>> pg_partition_tree() (an SRF) while developing a new related function,
>> pg_partition_ancestors(), and find the res
On Wed, Feb 27, 2019 at 03:48:08PM -0300, Alvaro Herrera wrote:
> I just happened to come across the result of this rationale in
> pg_partition_tree() (an SRF) while developing a new related function,
> pg_partition_ancestors(), and find the resulting behavior rather absurd
> -- it returns one row
On 2018-Dec-09, Tom Lane wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> ... especially in code that's highly unlikely to break once written.
>
> > I don't entirely buy off on the argument that it's code that's 'highly
> > unlikely to break once written' though- we
On Thu, Dec 13, 2018 at 03:34:56PM +0900, Amit Langote wrote:
> Thank you Michael for taking care of this. I agree with the consensus
> that instead of throwing an error for unsupported relkinds,
> pg_partition_tree should rather return single row containing NULL for all
> columns.
Cool, thanks f
On 2018/12/12 9:52, Michael Paquier wrote:
> On Mon, Dec 10, 2018 at 10:52:37PM +0900, Michael Paquier wrote:
>> OK. Sure, let's do as you suggest then. I'll wait a couple of days
>> before committing the patch so as if someone has extra comments they
>> have the time to post. So please feel fre
On Mon, Dec 10, 2018 at 10:52:37PM +0900, Michael Paquier wrote:
> OK. Sure, let's do as you suggest then. I'll wait a couple of days
> before committing the patch so as if someone has extra comments they
> have the time to post. So please feel free to comment!
And done this way. Thanks for th
On Mon, Dec 10, 2018 at 08:21:43AM -0500, Stephen Frost wrote:
> * Michael Paquier (mich...@paquier.xyz) wrote:
>> This still looks adapted to me. Or would you reword it because "allow"
>> rather implies that an ERROR is returned? Would you prefer changing it
>> something like that perhaps:
>> "R
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Sun, Dec 09, 2018 at 12:49:18PM -0500, Stephen Frost wrote:
> > Looks alright on a quick glance, but shouldn't you also update the
> > comment..?
>
> The comment on HEAD or with the patch is that:
> /* Only allow relation types th
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Sun, Dec 09, 2018 at 02:07:29PM -0500, Tom Lane wrote:
> > Stephen Frost writes:
> >> I don't entirely buy off on the argument that it's code that's 'highly
> >> unlikely to break once written' though- we do add new relkinds from time
On Sun, Dec 09, 2018 at 12:49:18PM -0500, Stephen Frost wrote:
> Looks alright on a quick glance, but shouldn't you also update the
> comment..?
The comment on HEAD or with the patch is that:
/* Only allow relation types that can appear in partition trees. */
This still looks adapted to me.
On Sun, Dec 09, 2018 at 02:07:29PM -0500, Tom Lane wrote:
> Stephen Frost writes:
>> I don't entirely buy off on the argument that it's code that's 'highly
>> unlikely to break once written' though- we do add new relkinds from time
>> to time, for example. Perhaps we could have these functions ru
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> ... especially in code that's highly unlikely to break once written.
> I don't entirely buy off on the argument that it's code that's 'highly
> unlikely to break once written' though- we do add new relkinds from time
> to time, for
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Michael Paquier (mich...@paquier.xyz) wrote:
> >> On Sat, Dec 08, 2018 at 08:46:08AM -0500, Stephen Frost wrote:
> >>> I wonder if we maybe should have a regression test for every such
> >>> function which just querie
Stephen Frost writes:
> * Michael Paquier (mich...@paquier.xyz) wrote:
>> On Sat, Dec 08, 2018 at 08:46:08AM -0500, Stephen Frost wrote:
>>> I wonder if we maybe should have a regression test for every such
>>> function which just queries the catalog in a way to force the function
>>> to be called
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Sun, Dec 09, 2018 at 08:15:07AM +0900, Michael Paquier wrote:
> > On Sat, Dec 08, 2018 at 08:46:08AM -0500, Stephen Frost wrote:
> >> We should really have a more clearly defined policy around this, but my
> >> recollection is that we
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Sat, Dec 08, 2018 at 08:46:08AM -0500, Stephen Frost wrote:
> > I wonder if we maybe should have a regression test for every such
> > function which just queries the catalog in a way to force the function
> > to be called for every rel
On Sun, Dec 09, 2018 at 08:15:07AM +0900, Michael Paquier wrote:
> On Sat, Dec 08, 2018 at 08:46:08AM -0500, Stephen Frost wrote:
>> We should really have a more clearly defined policy around this, but my
>> recollection is that we often prefer to return NULL rather than throwing
>> an error for th
On Sat, Dec 08, 2018 at 08:46:08AM -0500, Stephen Frost wrote:
> We should really have a more clearly defined policy around this, but my
> recollection is that we often prefer to return NULL rather than throwing
> an error for the convenience of people doing things like querying
> pg_class using si
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Fri, Dec 07, 2018 at 11:33:32PM -0500, Tom Lane wrote:
> > How about cases where the relation OID exists but it's the wrong
> > kind of relation?
>
> Such cases already return an error:
> =# create sequence popo;
> CREATE SEQUENCE
> =
On Fri, Dec 07, 2018 at 11:33:32PM -0500, Tom Lane wrote:
> How about cases where the relation OID exists but it's the wrong
> kind of relation?
Such cases already return an error:
=# create sequence popo;
CREATE SEQUENCE
=# select pg_partition_tree('popo');
ERROR: 42809: "popo" is not a table, a
Michael Paquier writes:
> On Fri, Dec 07, 2018 at 10:04:06AM +0900, Michael Paquier wrote:
>> I think that we should make the function return NULL if the relation
>> defined does not exist, as we usually do for system-facing functions.
>> It is also easier for the caller to know that the relation
On Sat, Dec 08, 2018 at 12:28:53PM +0900, Amit Langote wrote:
> Thanks for noticing it and creating the patch. The fix makes sense.
Thanks a lot for looking at it!
--
Michael
signature.asc
Description: PGP signature
Hi,
Sorry for not replying sooner.
On Sat, Dec 8, 2018 at 8:06 Michael Paquier wrote:
> On Fri, Dec 07, 2018 at 10:04:06AM +0900, Michael Paquier wrote:
> > While testing another patch, I have bumped into the issue of
> > $subject... I should have put some more negative testing from the start
On Fri, Dec 07, 2018 at 10:04:06AM +0900, Michael Paquier wrote:
> While testing another patch, I have bumped into the issue of
> $subject... I should have put some more negative testing from the start
> on this stuff, here is a culprit query when passing directly an OID:
> select pg_partition_tre
Hi all,
While testing another patch, I have bumped into the issue of
$subject... I should have put some more negative testing from the start
on this stuff, here is a culprit query when passing directly an OID:
select pg_partition_tree(0);
I think that we should make the function return NULL if t
36 matches
Mail list logo
