On Wed, Mar 14, 2018 at 02:15:03PM -0400, David Steele wrote:
> Do you mean a separate patch in this patch set, or a separate patch
> entirely? 02 depends on this logic, so I guess you mean create a new
> patch between 01 and 02?
Yes, one new patch that which can be applied on top of 1.
> Are yo
On Thu, Mar 15, 2018 at 02:03:15PM +0900, Kyotaro HORIGUCHI wrote:
> At Thu, 15 Mar 2018 00:33:25 -0400, Tom Lane wrote in
> <22193.1521088...@sss.pgh.pa.us>
>> Kyotaro HORIGUCHI writes:
>>> Doesn't it make sense if we provide a buildtime-script that
>>> collects the function names and builds a
At Mon, 12 Mar 2018 17:34:08 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20180312.173408.162882093.horiguchi.kyot...@lab.ntt.co.jp>
> > > In short, it's not really apparent to me that negative syscache entries
> > > are the major problem of this kind. I'm afraid that you're drawing
At Thu, 15 Mar 2018 00:33:25 -0400, Tom Lane wrote in
<22193.1521088...@sss.pgh.pa.us>
> Kyotaro HORIGUCHI writes:
> > Doesn't it make sense if we provide a buildtime-script that
> > collects the function names and builds a .h file containing a
> > function using the list?
>
> Surely this is a
On Tue, Mar 13, 2018 at 8:55 PM, Mat Arye wrote:
>>
>> Like cost associated with a function, we may associate mapping
>> cardinality with a function. It tells how many distinct input values
>> map to 1 output value. By input value, I mean input argument tuple. In
>> Mat's case the mapping cardinal
On Wed, Mar 14, 2018 at 10:46 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> committed
>
>
I'm getting compiler warnings:
pl_exec.c: In function 'exec_stmt_call':
pl_exec.c:2089:8: warning: variable 'numargs' set but not used
[-Wunused-but-set-variable]
int numargs;
Kyotaro HORIGUCHI writes:
> Doesn't it make sense if we provide a buildtime-script that
> collects the function names and builds a .h file containing a
> function using the list?
Surely this is a fundamentally misguided approach. How could it
handle extension GUCs?
regar
Hello,
At Wed, 14 Mar 2018 17:46:21 +0900, Michael Paquier wrote
in <20180314084621.ga...@paquier.xyz>
> On Wed, Mar 14, 2018 at 05:30:59PM +0900, Kyotaro HORIGUCHI wrote:
> > Doesn't it make sense if we provide a buildtime-script that
> > collects the function names and builds a .h file contain
On Wed, Mar 14, 2018 at 10:11 PM, Stephen Frost wrote:
> Greetings Ashutosh,
>
> * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
>> Here are two patches fixing comments.
>
> Thanks!
>
>> 0001
>> A comment in add_paths_to_append_rel() mentions the number of paths
>> instead of number of w
Hi Stephen,
(2018/03/14 22:28), Stephen Frost wrote:
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
Here is a small patch to fix $SUBJECT, which I think is my fault when
working on direct foreign-table modification. Sorry about that.
Fixed.
Thanks!
Best regards,
Etsuro Fujita
Hi,
On 2018-03-14 22:36:52 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-03-13 15:29:33 -0700, Andres Freund wrote:
> >> On 2018-03-14 10:32:40 +1300, Thomas Munro wrote:
> >>> It looks
> >>> like -fexcess-precision-standard is coming from a configure test that
> >>> was run against
Dave Page writes:
>> On 14 Mar 2018, at 19:14, Mark Wong wrote:
>> Since the buildfarm is composed of animals, I thought plants would be a
>> complimentary scheme? I'm also not sure if this was discussed
>> previously...
> For some reason I was thinking fish!
There's already a fair number of f
Thomas Munro writes:
> On Thu, Mar 15, 2018 at 3:32 PM, Tom Lane wrote:
>> ... I manually filtered
>> out a bunch of non-problems, in particular discarding names that are in
>> per-test schemas; I think it's all right to allow tests that are taking
>> that precaution to do what they like name-wis
> On 14 Mar 2018, at 19:14, Mark Wong wrote:
>
> Hi,
>
> I have some additional comments to a couple areas...
>
>> On Wed, Mar 14, 2018 at 05:33:00PM -0400, Dave Page wrote:
>>> On Tue, Mar 13, 2018 at 11:31 PM, Hongyuan Ma wrote:
>>> At the same time I hope you can help me understand the fu
On Thu, Mar 15, 2018 at 3:32 PM, Tom Lane wrote:
> ... I manually filtered
> out a bunch of non-problems, in particular discarding names that are in
> per-test schemas; I think it's all right to allow tests that are taking
> that precaution to do what they like name-wise.
What if we always did th
On Thu, Mar 15, 2018 at 12:06 AM, Alvaro Herrera
wrote:
> Hello,
>
> Ildar Musin wrote:
>
>> autovac_get_workitem_name() declaration seems redundant and should be
>> removed. The same thing with including "utils/lsyscache.h" in brin.c.
>>
>> The 'requested' variable in brininsert() I would again r
Andres Freund writes:
> On 2018-03-13 15:29:33 -0700, Andres Freund wrote:
>> On 2018-03-14 10:32:40 +1300, Thomas Munro wrote:
>>> It looks
>>> like -fexcess-precision-standard is coming from a configure test that
>>> was run against ${CC}, not against ${CLANG}, so I hacked the generated
>>> src/
Thomas Munro writes:
> On Thu, Mar 15, 2018 at 12:31 PM, Tom Lane wrote:
>> Moral: choose names less generic than "test" for globally-visible
>> objects. I wonder if there's some way we could check for such
>> conflicts automatically?
> Ugh. Yeah. Non-temporary table and view names used in mo
On Wed, Mar 14, 2018 at 12:05 PM, Claudio Freire wrote:
> On Wed, Mar 14, 2018 at 1:36 AM, Pavan Deolasee
> wrote:
>>
>>
>> On Sun, Mar 11, 2018 at 9:18 PM, Claudio Freire
>> wrote:
>>>
>>> On Sun, Mar 11, 2018 at 2:27 AM, Pavan Deolasee
>>>
>>> >
>>> > Yes, I will try that next - it seems like
On Thu, Mar 15, 2018 at 12:31 PM, Tom Lane wrote:
> guaibasaurus just failed in a way I'd not seen before:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=guaibasaurus&dt=2018-03-14%2006%3A33%3A01
>
> Inspection of the diffs makes it depressingly obvious what happened:
> the concurrent
On 15 March 2018 at 05:07, Andres Freund wrote:
> On 2018-03-14 14:34:38 +1300, David Rowley wrote:
>> It would be nice to see us completely get rid of all the
>> appendStringInfo* calls, apart from in the functions which meant to
>> handle the behaviour specific to the explain format. This is a s
On Wed, Mar 14, 2018 at 03:36:28PM -0400, Peter Eisentraut wrote:
> done
Thanks Peter. One done, 150 remaining.
--
Michael
signature.asc
Description: PGP signature
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 2da536c0f6a081a50cb708de3ad6631345ec8dca Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Wed, 14 Mar 2018 16:47:44 -0300
Subject: [PATCH] test module
--
Masahiko Sawada wrote:
> Regarding to regression test, I added a new test module
> test_subscription that creates a new user-defined data type. In a
> subscription regression test, using test_subscription we make
> subscriber call slot_store_error_callback and check if the subscriber
> can correct
Hi,
On 03/10/2018 06:19 PM, Alvaro Herrera wrote:
> On 0002:
>
> In terms of docs, I think it's better not to have anything
> user-facing in the README. Consider that users are going to be
> reading the HTML docs only, and many of them may not have the README
> available at all. So anything that
Hi,
On 2018-03-13 15:29:33 -0700, Andres Freund wrote:
> On 2018-03-14 10:32:40 +1300, Thomas Munro wrote:
> > I decided to try this on a CentOS 7.2 box. It has LLVM 3.9 in the
> > 'epel' package repo, but unfortunately it only has clang 3.4.
>
> That's a bit odd, given llvm and clang really liv
On Wed, Mar 14, 2018 at 2:56 PM, Jeff Janes wrote:
> On Tue, Mar 13, 2018 at 4:57 PM, Thomas Munro
> wrote:
>> Here's a patch to remove LIMIT 1, which fixes the plan for Jeff's test
>> scenario and some smaller and larger examples I tried. The query is
>> already executed with SPI_execute(..., 1
guaibasaurus just failed in a way I'd not seen before:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=guaibasaurus&dt=2018-03-14%2006%3A33%3A01
Inspection of the diffs makes it depressingly obvious what happened:
the concurrently-executing "alter_table" and "with" scripts both create
sho
Hi,
I have some additional comments to a couple areas...
On Wed, Mar 14, 2018 at 05:33:00PM -0400, Dave Page wrote:
> On Tue, Mar 13, 2018 at 11:31 PM, Hongyuan Ma wrote:
> > At the same time I hope you can help me understand the functional
> > requirements of this project more clearly. Here are
Hi
On Tue, Mar 13, 2018 at 11:31 PM, Hongyuan Ma wrote:
> Hi Dave,
> I am willing to use React to re-create the front-end application. Since I
> plan to use separate front-end and back-end development methods, this means
> that there will be no html files in Django applications. Front-end and
>
On 3/14/18 01:47, Michael Paquier wrote:
>> For the other flags we would probably need to test what impact would it
>> have (e.g. table with no indexes, many indexes on other tables, and
>> something calling get_relation_info a lot). But this patch proposes to
>> remove only relhaspkey.
>
> Yes, y
2018-03-14 15:11 GMT+01:00 Alexander Korotkov :
> On Wed, Mar 14, 2018 at 2:10 AM, Andres Freund wrote:
>
>> On 2018-03-14 07:54:35 +0900, Michael Paquier wrote:
>> > On Tue, Mar 13, 2018 at 04:08:01PM +0300, Oleg Bartunov wrote:
>> > > The docs are here
>> > > https://github.com/obartunov/sqljso
Alvaro Herrera wrote:
> Yeah, seems a reasonable idea to me. Here's a tidied-up version of your
> patch, minus the regression test changes (I may end up committing that
> one separately).
... and patch.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
On Tue, Mar 13, 2018 at 4:02 AM, Narendra Pradeep U U <
narendra.prad...@zohocorp.com> wrote:
> Hi,
> Thanks everyone for your suggestions. I would like to add explain
> analyze of both the plans so that we can have broader picture.
>
> I have a work_mem of 1000 MB.
>
Is it possible to rep
Hi Michael,
On 3/13/18 9:31 PM, Michael Paquier wrote:
> On Tue, Mar 13, 2018 at 12:19:07PM -0400, David Steele wrote:
>> I'll attach new patches in a reply to [1] once I have made the changes
>> Tom requested.
>
> Cool, thanks for your patience. Looking forward to seeing those. I'll
> spend ti
On Wed, Mar 14, 2018 at 5:16 AM, David Rowley
wrote:
> Thanks for putting the patch together. Although in regards to your
> proposed commit message in the patch, I'd disagree with me having just
> reported it. I also investigated it and suggested a fix, which happens
> to be exactly the fix you've
John Naylor writes:
> It didn't take that long to rebase the remaining parts of the
> patchset, so despite what I said above I went ahead and put them in
> version 10 (attached), this time via scripted bulk editing rather than
> as large patches.
Starting to look into this version now, but a smal
Hi,
On 3/13/18 12:13 PM, Stephen Frost wrote:
> * David Steele (da...@pgmasters.net) wrote:
>> On 3/13/18 11:00 AM, Tom Lane wrote:
>>>
>>> FWIW, I took a quick look through this patch and don't have any problem
>>> with the approach, which appears to be "use the data directory's
>>> startup-time
Hi,
On 2018-03-13 17:27:40 -0700, Andres Freund wrote:
> while adding EXPLAIN support for JITing (displaying time spent etc), I
> got annoyed by the amount of duplication required. There's a fair amount
> of
> if (es->format == EXPLAIN_FORMAT_TEXT)
> appendStringInfo(es->str, "Executio
Masahiko Sawada wrote:
> After more thought, I think since the errors in
> logicalrep_typmap_gettypname are not relevant with the actual error
> (i.g. type conversion error) it would not be good idea to show the
> error message of "could not found data type entry" in errcontext.
> It might be more
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Andres Freund writes:
> On 2018-03-14 13:32:10 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> Only thing I wonder is if we shouldn't just *remove*
>>> ExplainPropertyLong and make ExplainPropertyInteger accept 64bits of
>>> input - the effort of passing and printing a 64bit integer will neve
Hi,
On 2018-03-14 13:32:10 -0400, Tom Lane wrote:
> Andres Freund writes:
> > If we do this, and I think we should, I'm inclined to also commit a
> > patch that renames ExplainPropertyLong
> > and changes its argument type. Because passing long is just plain
> > unhelpful for 32bit platforms and
Andres Freund writes:
> If we do this, and I think we should, I'm inclined to also commit a
> patch that renames ExplainPropertyLong
> and changes its argument type. Because passing long is just plain
> unhelpful for 32bit platforms and windows. We should just always use
> 64bits here.
+1 --- I'
Hi,
On 2018-03-13 17:27:40 -0700, Andres Freund wrote:
> Hi,
>
> while adding EXPLAIN support for JITing (displaying time spent etc), I
> got annoyed by the amount of duplication required. There's a fair amount
> of
> if (es->format == EXPLAIN_FORMAT_TEXT)
> appendStringInfo(es->str,
Greetings Ashutosh,
* Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> Here are two patches fixing comments.
Thanks!
> 0001
> A comment in add_paths_to_append_rel() mentions the number of paths
> instead of number of workers by mistake. Fixed it.
This looks alright.
> 0002
> Commit b5
Hi,
On 2018-03-14 14:34:38 +1300, David Rowley wrote:
> On 14 March 2018 at 13:27, Andres Freund wrote:
> > In the attached *POC* patch I've added a 'unit' parameter to the numeric
> > ExplainProperty* functions, which EXPLAIN_FORMAT_TEXT adds to the
> > output. This can avoid the above and othe
Hi,
Given
-- test.sql --
CREATE TABLE t1 (
a integer NOT NULL,
b integer NOT NULL
) PARTITION BY HASH (b);
CREATE TABLE t1_p00 PARTITION OF t1 FOR VALUES WITH (MODULUS 4,
REMAINDER 0);
CREATE TABLE t1_p01 PARTITION OF t1 FOR VALUES WITH (MODULUS 4,
REMAINDER 1);
CREATE TABLE t1_p02
Hello,
Ildar Musin wrote:
> autovac_get_workitem_name() declaration seems redundant and should be
> removed. The same thing with including "utils/lsyscache.h" in brin.c.
>
> The 'requested' variable in brininsert() I would again rename to something
> like 'success' because a work item is request
On Wed, Mar 14, 2018 at 1:36 AM, Pavan Deolasee
wrote:
>
>
> On Sun, Mar 11, 2018 at 9:18 PM, Claudio Freire
> wrote:
>>
>> On Sun, Mar 11, 2018 at 2:27 AM, Pavan Deolasee
>>
>> >
>> > Yes, I will try that next - it seems like a good idea. So the idea would
>> > be:
>> > check if the block is sti
On Tue, Mar 13, 2018 at 7:43 PM, Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
> Hi,
>
> The patch-set is complete now. But still, there is a scope of some comment
> improvements due to all these refactorings. I will work on it. Also, need
> to update few documentations and indentations e
On 3/13/18 12:46, Alvaro Herrera wrote:
> Dagfinn Ilmari Mannsåker wrote:
>
>> $SIG{__DIE__} gets called even for exceptions that would be caught by a
>> surrunding eval block, so this should at the very least be:
>>
>> $SIG{__DIE__} = sub { BAIL_OUT(@_) unless $^S };
>>
>> However, that is st
On Wed, Mar 14, 2018 at 7:21 PM, Simon Riggs
wrote:
> On 14 March 2018 at 13:33, Pavan Deolasee
> wrote:
> >
> >
> > On Wed, Mar 14, 2018 at 4:53 PM, Simon Riggs <
> simon.ri...@2ndquadrant.com>
> > wrote:
> >>
> >> On 14 March 2018 at 04:36, Pavan Deolasee
> >> wrote:
> >> > I wonder if the sh
On Wed, Mar 14, 2018 at 2:10 AM, Andres Freund wrote:
> On 2018-03-14 07:54:35 +0900, Michael Paquier wrote:
> > On Tue, Mar 13, 2018 at 04:08:01PM +0300, Oleg Bartunov wrote:
> > > The docs are here
> > > https://github.com/obartunov/sqljsondoc/blob/master/README.jsonpath.md
> > >
> > > It's not
On Wed, Mar 14, 2018 at 10:51 AM, Simon Riggs
wrote:
> If there is enough delay in step 1 then any benefit is lost anyway, so
> there is no point taking the cached path even when successful, so its
> better to ignore in that case.
I find myself agreeing with that.
On 14 March 2018 at 13:33, Pavan Deolasee wrote:
>
>
> On Wed, Mar 14, 2018 at 4:53 PM, Simon Riggs
> wrote:
>>
>> On 14 March 2018 at 04:36, Pavan Deolasee
>> wrote:
>> > I wonder if the shortened code path actually leads to
>> > heavier contention for EXCLUSIVE lock on the rightmost page, whic
On 3/14/18 9:07 AM, Peter Eisentraut wrote:
> On 3/13/18 10:12, David Steele wrote:
>> A new patch is attached.
>
> Committed.
Thanks, Peter!
--
-David
da...@pgmasters.net
On Wed, Mar 14, 2018 at 4:53 PM, Simon Riggs
wrote:
> On 14 March 2018 at 04:36, Pavan Deolasee
> wrote:
> > I wonder if the shortened code path actually leads to
> > heavier contention for EXCLUSIVE lock on the rightmost page, which in
> turn
> > causes the slowdown. But that's just a theory. A
Greetings Etsuro,
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
> Here is a small patch to fix $SUBJECT, which I think is my fault when
> working on direct foreign-table modification. Sorry about that.
Fixed.
Thanks!
Stephen
signature.asc
Description: PGP signature
On 3/13/18 10:12, David Steele wrote:
> A new patch is attached.
Committed.
I removed the cleanup code at the end of the test file, since that is
done automatically.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Service
Hello Teodor,
On 07.03.2018 16:21, Ildar Musin wrote:
Turned out that the only big-endian machine I could run test on is
out of order.
I finally managed to perform this test on sparc v9 machine which is 64
bit big-endian architecture. I run pgbench script (see previous message)
with default_se
On Wed, Mar 14, 2018 at 7:40 AM, Masahiko Sawada
wrote:
> On Sat, Mar 10, 2018 at 3:40 AM, Alexander Korotkov
> wrote:
> > On Fri, Mar 9, 2018 at 3:12 PM, Masahiko Sawada
> > wrote:
> >>
> >> On Fri, Mar 9, 2018 at 8:43 AM, Alexander Korotkov
> >> wrote:
> >> > 2) These parameters are reset du
On 12 March 2018 at 08:41, Peter Geoghegan wrote:
> On Sun, Mar 11, 2018 at 3:22 AM, David Rowley
>> A perhaps simple fix would be just to have ResetReindexPending() only
>> reset the list to NIL again and not try to raise any error.
>
> I noticed a very similar bug in ResetReindexProcessing() jus
On Tue, 13 Mar 2018 11:08:36 -0400
Peter Eisentraut wrote:
> On 3/6/18 07:48, Ildus Kurbangaliev wrote:
> > Although as was discussed before it seems inconsistent without
> > ROLLBACK support. There was a little discussion about it, but no
> > replies. Maybe the status of the patch should be chan
On 14 March 2018 at 00:37, Amit Langote wrote:
> Attached is a significantly revised version of the patch, although I admit
> it could still use some work with regard to comments and other cleanup.
Thanks for making all those changes. There's been quite a bit of churn!
I've looked over the patch
On 14 March 2018 at 04:36, Pavan Deolasee wrote:
> I wonder if the shortened code path actually leads to
> heavier contention for EXCLUSIVE lock on the rightmost page, which in turn
> causes the slowdown. But that's just a theory. Any ideas how to prove or
> disprove that theory or any other point
Hi
Here are two patches fixing comments.
0001
A comment in add_paths_to_append_rel() mentions the number of paths
instead of number of workers by mistake. Fixed it.
0002
Commit b5635948ab165b6070e7d05d111f966e07570d81 added a single
grouping_sets_data argument instead of two lists related to grou
On Wed, Mar 14, 2018 at 9:25 PM, Etsuro Fujita
wrote:
> (2018/03/14 14:54), Amit Langote wrote:
>> On 2018/03/06 21:26, Etsuro Fujita wrote:
>>> if (mtstate->mt_transition_capture != NULL)
>>> {
>>> if (resultRelInfo->ri_TrigDesc&&
>>> (resultRelInfo->ri_TrigDesc->t
On 2018/03/14 8:26, Alvaro Herrera wrote:
> By the way, I checked whether patch 0002 (additional tests) had an
> effect on coverage, and couldn't detect any changes in terms of
> lines/functions. Were you able to find any bugs in your code thanks to
> the new tests that would not have been covered
On Wed, Mar 14, 2018 at 09:26:15AM +0900, Tatsuo Ishii wrote:
> > select [...] where nspname operator(pg_catalog.=) '%s'
> Next question is, should we update the manual? There are bunch of
> places where example queries are shown without schema qualifications.
I gave https://www.postgresql.org/d
On Wed, Mar 14, 2018 at 05:30:59PM +0900, Kyotaro HORIGUCHI wrote:
> Doesn't it make sense if we provide a buildtime-script that
> collects the function names and builds a .h file containing a
> function using the list?
>
> The attached perl script is a rush work of such script, which
> works at t
Here is a small patch to fix $SUBJECT, which I think is my fault when
working on direct foreign-table modification. Sorry about that.
Best regards,
Etsuro Fujita
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index c32928d..3332ae4 100644
--- a/src/ba
On 2018/03/14 17:35, Etsuro Fujita wrote:
> (2018/03/14 17:25), Etsuro Fujita wrote:
>> (2018/03/14 14:54), Amit Langote wrote:
>>> Sorry that this may be nitpicking that I should've brought up before, but
>>> doesn't ExecPrepareTupleRouting do all the work that's needed for routing
>>> a tuple and
(2018/03/14 17:25), Etsuro Fujita wrote:
(2018/03/14 14:54), Amit Langote wrote:
Sorry that this may be nitpicking that I should've brought up before, but
doesn't ExecPrepareTupleRouting do all the work that's needed for routing
a tuple and hence isn't the name a bit misleading? Maybe,
ExecPerfo
Hello leap,
> hello!
> I develop a tool for pgsql, I want to submit it on pgsql.
> how can I submit it?
> address: https://github.com/leapking/pgcheck
It's always nice to see another great tool! Thanks a lot for sharing it.
I believe you should write a blog post about it for PostgreSQL Planet or
Hello,
At Tue, 6 Mar 2018 07:14:00 +0100, Pavel Stehule
wrote in
> 2018-03-06 2:32 GMT+01:00 Michael Paquier :
>
> > On Mon, Mar 05, 2018 at 09:25:09PM +0100, Pavel Stehule wrote:
> > > I afraid so there is not good solution. Is possible to store options in
> > > original form? When the functi
(2018/03/14 14:54), Amit Langote wrote:
On 2018/03/06 21:26, Etsuro Fujita wrote:
One thing I notice while working on this is this in ExecInsert/CopyFrom,
/*
* If we're capturing transition tuples, we might need to convert from
the
* partition rowtype to parent rowtype.
On 2018/03/14 17:16, Amit Langote wrote:
> On 2018/03/10 13:40, Tom Lane wrote:
>> I wrote:
>>> I think it'd make more sense to see about incorporating that idea in
>>> predicate_implied_by_simple_clause/predicate_refuted_by_simple_clause.
>>
>> After further thought, it seems like the place to dea
On 2018/03/10 13:40, Tom Lane wrote:
> I wrote:
>> I think it'd make more sense to see about incorporating that idea in
>> predicate_implied_by_simple_clause/predicate_refuted_by_simple_clause.
>
> After further thought, it seems like the place to deal with this is
> really operator_predicate_proo
Hello Stephen,
> > Protobuf is fine too, but unfortunately we don't have any
> > Protobuf-related projects this time.
>
> Just to be clear, the list on the wiki is just a set of suggestions-
> students are welcome to propose their own projects as well.
Oh, I didn't know that. In this case I will
80 matches
Mail list logo
