On 2019-Mar-26, Peter Eisentraut wrote:
> On 2019-03-26 03:42, Alvaro Herrera wrote:
> > Patch tester didn't like that one bit. Here's v10 with the fixup
> > applied.
>
> Looks good to me.
Thanks!
I ran "make installcheck-parallel" using this psql version on all
supported branches plus 9.2. T
On 2019-03-26 03:42, Alvaro Herrera wrote:
> Patch tester didn't like that one bit. Here's v10 with the fixup
> applied.
Looks good to me.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Patch tester didn't like that one bit. Here's v10 with the fixup
applied.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 4e352a1b3a0730f2c3e91e6d62335d6db6823796 Mon Sep 17 00:00:00 2001
From: Alvaro Herre
Hi,
On 2019/03/26 7:38, Alvaro Herrera wrote:
> v9 attached; this one's final AFAICT.
Agreed.
Thanks,
Amit
On 2019-Mar-25, Alvaro Herrera wrote:
> v9 attached; this one's final AFAICT.
Actually, I propose this fixup. It doesn't change the current output,
but of course it affects how this works with my patch in
https://postgr.es/m/20190321215420.GA22766@alvherre.pgsql
The v9 patch does not show anythi
v9 attached; this one's final AFAICT.
On 2019-Mar-25, Peter Eisentraut wrote:
> relispartition was added in PG10, so the conditional in
> describeOneTableDetails() seems wrong.
Hmm, yeah, we weren't using it anyway (since we can only use the new
display with pg_partition_ancestors which is new i
On 2019-03-23 03:30, Alvaro Herrera wrote:
>>> Thanks for the updated patch. I applied it and rebased the
>>> foreign-keys-referencing-partitioned-tables patch on top. Here's
>>> something I think you may have missed:
>>
>> I missed that indeed! Thanks for noticing. Here's an updated and
>> reb
On 2019-Mar-22, Alvaro Herrera wrote:
> On 2019-Mar-05, Amit Langote wrote:
>
> > On 2019/03/05 4:41, Alvaro Herrera wrote:
> > > Here's the patch I'm really interested about :-)
> >
> > Thanks for the updated patch. I applied it and rebased the
> > foreign-keys-referencing-partitioned-tables p
On 2019-Mar-05, Amit Langote wrote:
> On 2019/03/05 4:41, Alvaro Herrera wrote:
> > Here's the patch I'm really interested about :-)
>
> Thanks for the updated patch. I applied it and rebased the
> foreign-keys-referencing-partitioned-tables patch on top. Here's
> something I think you may have
On 2019/03/05 4:41, Alvaro Herrera wrote:
> Here's the patch I'm really interested about :-)
Thanks for the updated patch. I applied it and rebased the
foreign-keys-referencing-partitioned-tables patch on top. Here's
something I think you may have missed:
-- partitioned primary key table
create
On 2019-Feb-28, Michael Paquier wrote:
> On Wed, Feb 27, 2019 at 03:37:23PM -0300, Alvaro Herrera wrote:
> > +pg_partition_ancestors(PG_FUNCTION_ARGS)
> > +{
> > + Oid relid = PG_GETARG_OID(0);
> > + FuncCallContext *funcctx;
> > + ListCell **next;
> > +
> > + if (!ch
On Wed, Feb 27, 2019 at 03:37:23PM -0300, Alvaro Herrera wrote:
> It should have listed t2 too, but it doesn't. Since these functions
> aren't supposed to work on legacy inheritance anyway, I think the right
> action is to return the empty set. In the current version I just do
> what pg_partition
On 2019-Feb-27, Michael Paquier wrote:
> On Tue, Feb 26, 2019 at 07:27:57PM -0300, Alvaro Herrera wrote:
> > Thanks for committing pg_partition_root ... but it turns out to be
> > useless for this purpose.
>
> Well, what's done is done. The thing is useful by itself in my
> opinion.
Eh, of cour
On Tue, Feb 26, 2019 at 07:27:57PM -0300, Alvaro Herrera wrote:
> Thanks for committing pg_partition_root ... but it turns out to be
> useless for this purpose.
Well, what's done is done. The thing is useful by itself in my
opinion.
> It turns out that we need to obtain the list
> of *ancestors*
On 2019-Feb-04, Michael Paquier wrote:
> pg_partition_root() has not made it to the finish line yet, still it
> would have been nice to see a rebase, and the patch has been waiting
> for input for 4 weeks now. So I am marking it as returned with
> feedback.
Thanks for committing pg_partition_roo
On Wed, Jan 02, 2019 at 09:38:40PM +0100, Peter Eisentraut wrote:
> I'm setting this to "Waiting on Author", awaiting a new version based on
> pg_partition_root() once that one is done.
pg_partition_root() has not made it to the finish line yet, still it
would have been nice to see a rebase, and t
On 06/12/2018 23:56, Michael Paquier wrote:
> On Thu, Dec 06, 2018 at 01:26:30PM -0300, Alvaro Herrera wrote:
>> That means I can just get pg_partition_root() done first, and try to
>> write the queries using that instead of WITH RECURSIVE.
>
> FWIW, I was just writing a patch about this one, so I
On Thu, Dec 06, 2018 at 01:26:30PM -0300, Alvaro Herrera wrote:
> That means I can just get pg_partition_root() done first, and try to
> write the queries using that instead of WITH RECURSIVE.
FWIW, I was just writing a patch about this one, so I was going to spawn
a new thread today :)
Let's def
On 2018-Dec-06, Robert Haas wrote:
> On Wed, Dec 5, 2018 at 11:30 AM Alvaro Herrera
> wrote:
> > I added this patch to commitfest in order to get more opinions,
> > particularly on whether to backpatch this. I might commit sooner than
> > that if others care to comment.
>
> I don't think this
On Wed, Dec 5, 2018 at 11:30 AM Alvaro Herrera wrote:
> I added this patch to commitfest in order to get more opinions,
> particularly on whether to backpatch this. I might commit sooner than
> that if others care to comment.
I don't think this is a bug fix, and therefore I oppose back-patching
On 2018-Dec-04, Alvaro Herrera wrote:
> On 2018-Dec-04, Alvaro Herrera wrote:
>
> > v2 attached.
>
> Oops.
One more oops: The version I posted was for pg11, and does not apply to
master. This version applies to master.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL
I added this patch to commitfest in order to get more opinions,
particularly on whether to backpatch this. I might commit sooner than
that if others care to comment.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Service
On 2018-Dec-05, Michael Paquier wrote:
> This has been mentioned on the thread where pg_partition_tree has been
> discussed:
> https://www.postgresql.org/message-id/6baeb45a-6222-6b88-342d-37fc7d3cf89a%40lab.ntt.co.jp
>
> It got shaved from the final patch for simplicity as we had enough
> issues
On Tue, Dec 04, 2018 at 03:41:59PM -0300, Alvaro Herrera wrote:
> I spent a few minutes trying to think of a way of determining which
> query to use at SQL-execution time -- two CTEs, one of which would be
> short-circuited ... but I couldn't figure out how. I also tried to use
> the new pg_partit
On 2018-Dec-04, Alvaro Herrera wrote:
> v2 attached.
Oops.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 4015ed3741e81528882761252ddf463d4c10aed5 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Tue,
On 2018-Dec-04, Tom Lane wrote:
> ... this patch breaks the expectation set at the top of describe.c:
>
> * Support for the various \d ("describe") commands. Note that the current
> * expectation is that all functions in this file will succeed when working
> * with servers of versions 7.4 and
On 2018-Dec-04, David Fetter wrote:
> On Tue, Dec 04, 2018 at 10:00:00AM -0500, Tom Lane wrote:
> > That's probably a win performance-wise anyway, as I have no doubt
> > that the performance of this query is awful compared to what it
> > replaces, so we don't really want to use it if we don't hav
On Tue, Dec 04, 2018 at 10:00:00AM -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > This is not very useful. I propose that we change it so that it only
> > displays the one on the partitioned table on which the constraint was
> > defined:
>
> OK goal, but ...
>
> > Patch attached.
>
> ...
Alvaro Herrera writes:
> This is not very useful. I propose that we change it so that it only
> displays the one on the partitioned table on which the constraint was
> defined:
OK goal, but ...
> Patch attached.
... this patch breaks the expectation set at the top of describe.c:
* Support fo
When \d a table referenced by a foreign key on a partitioned table, you
currently get this:
Table "public.referenced"
Column | Type | Collation | Nullable | Default
+-+---+--+-
a | integer | | not null |
Indexes:
"refer
30 matches
Mail list logo
