On Wed, 23 Jan 2019 at 06:35, Tomas Vondra wrote:
> It turned out to be a tad more complex due to partitioning, because when
> we find the partitions do not match, the tuple is already allocated in
> the "current" context (be it per-tuple or batch). So we can't just free
> the whole context at
On 2019-Jan-28, Tom Lane wrote:
> (There was some mention of trying to split relation.h into multiple
> files, but I fail to see any advantage in that.)
Hmm, nodes/relation.h includes lots of other files and is widely
included. If we can split it usefully, I vote for that. However, I
failed to
On 2019/01/28 20:27, David Rowley wrote:
> On Mon, 28 Jan 2019 at 20:45, Amit Langote
> wrote:
>> It seems to me that plancache.c doesn't really need to perform
>> AcquireExecutorLocks()/LockRelationOid() to learn that a partition's
>> reloptions property has changed to discard a generic plan and
> 29 янв. 2019 г., в 7:32, Andreas Karlsson написал(а):
>
> On 1/28/19 7:26 PM, Andrey Borodin wrote:
>>> * I am no fan of the tupdesc vs truncTupdesc separation and think that it
>>> is a potential hazard, but I do not have any better suggestion right now.
>> B-tree is copying tupdesc every
Sven Berkvens-Matthijsse writes:
> In 2016, a thread was started about implementing INSERT INTO ... SET ...
> that included a patch and was basically ready for inclusion in
> PostgreSQL. However, it seems as though it stagnated for some reason.
> Does anybody remember this and is there perhaps
On Tue, 29 Jan 2019 at 09:55, Tom Lane wrote:
> Simon Riggs writes:
> > On Sun, 27 Jan 2019 at 19:17, Tom Lane wrote:
> >> ... I don't
> >> know whether that would satisfy your concern, because I'm not clear
> >> on what your concern is.
>
> > To be able to extract indexable clauses where none
Simon Riggs writes:
> On Sun, 27 Jan 2019 at 19:17, Tom Lane wrote:
>> ... I don't
>> know whether that would satisfy your concern, because I'm not clear
>> on what your concern is.
> To be able to extract indexable clauses where none existed before.
That's a pretty vague statement, because it
Hi,
Peter Eisentraut wrote:
> When you manage the WAL (or perhaps in the future relation files)
> through PMDK, is there still a file system view of it somewhere, for
> browsing, debugging, and for monitoring tools?
First, I assume that our patchset is used with a filesystem that supports
direct
On Sun, 27 Jan 2019 at 19:17, Tom Lane wrote:
> > * Allow a normal term to match a functional index, e.g. WHERE x =
> > 'abcdefgh' => WHERE substr(x, 1 , 5) = 'abcde' AND x = 'abcdefgh'
>
> I'm a bit confused about what you think this example means. I do
> intend to work on letting extensions
On Mon, 28 Jan 2019 at 20:15, Robert Haas wrote:
> On Fri, Jan 25, 2019 at 4:18 PM Alvaro Herrera
> wrote:
> > Right, the planner/executor "disconnect" is one of the challenges, and
> > why I was trying to keep the old copy of the PartitionDesc around
> > instead of building updated ones as
On Mon, Jan 28, 2019 at 02:00:59PM +0100, Alex Kliukin wrote:
> While reading the doc page for the pg_basebackup, I've been confused
> by the fact that it says WAL files will be written to .tarballs
> (either base.tar or pg_wal.tar) when pg_basebackup is instructed to
> stream WALs alongside the
On Mon, Jan 28, 2019 at 10:33:06PM +0100, Dimitri Fontaine wrote:
> In other cases, it's important to measure and accept the possible
> performance cost of running a proxy server between the client connection
> and the PostgreSQL backend process. I believe the numbers shown in the
> previous email
On Tue, Jan 29, 2019 at 12:35:30AM +, Jamison, Kirk wrote:
> I just checked the patch.
> As per advice, you removed the versioning and specified --jobs.
> The patch still applies, builds and passed the tests successfully.
I would document the optional VACUUM_OPTS on the page of pg_upgrade.
On Mon, Jan 28, 2019 at 05:05:32PM -0500, Tom Lane wrote:
> Yeah, I thought about that too, but it doesn't seem like an improvement.
> If the query is very long (which isn't unlikely) I think people would
> prefer to see the option(s) up front.
Having these options at the front of the WITH clause
On Tue, Jan 29, 2019 at 12:18:29PM +0900, Kyotaro HORIGUCHI wrote:
> At Mon, 28 Jan 2019 14:53:43 +0100, Peter Eisentraut
> wrote in
> <24783370-5acd-e0f3-8eb7-7f42ff2a0...@2ndquadrant.com>
>> This is strange. The tests work for me, and also on the cfbot. The
>
> Agreed. It seemed so also to
On Tue, Jan 29, 2019 at 11:49:37AM +0900, Takashi Menjo wrote:
> Because of pg_pwrite()[1], openLogOff, a static global variable in xlog.c,
> seems taken over by a local variable startoffset and no longer used
> now.
It seems to me that keeping openLogOff is still useful to get a report
about the
Hi all,
In 2016, a thread was started about implementing INSERT INTO ... SET ...
that included a patch and was basically ready for inclusion in
PostgreSQL. However, it seems as though it stagnated for some reason.
Does anybody remember this and is there perhaps someone who knows what
the
Andres Freund writes:
> I did that now. I couldn't reproduce it locally, despite a lot of
> runs. Looking at the buildfarm it looks like the failures were,
> excluding handfish which failed without recognizable symptoms before and
> after, on BSD derived platforms (netbsd, freebsd, OX), which
(2019/01/28 19:37), Etsuro Fujita wrote:
> (2019/01/25 20:33), Etsuro Fujita wrote:
>> I noticed yet another thing while updating the patch for pushing down
>> ORDER BY LIMIT. Let me explain. When costing foreign paths on the
>> basis of local statistics, we calculate/cache the costs of an
At Mon, 28 Jan 2019 17:30:57 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190128.173057.41178374.horiguchi.kyot...@lab.ntt.co.jp>
> At Wed, 26 Dec 2018 12:59:32 -0500, Tom Lane wrote in
> <32289.1545847...@sss.pgh.pa.us>
> > Hm, I agree that the para doesn't read very well now,
Hi,
On 2019-01-28 16:40:36 -0800, Andres Freund wrote:
> On 2019-01-28 15:49:33 -0800, Andres Freund wrote:
> > On 2019-01-28 18:08:59 -0500, Tom Lane wrote:
> > > Andres Freund writes:
> > > > I'm inclined to put back the
> > > >LockBuffer(buf, BUFFER_LOCK_UNLOCK);
> > > >
At Mon, 28 Jan 2019 14:53:43 +0100, Peter Eisentraut
wrote in
<24783370-5acd-e0f3-8eb7-7f42ff2a0...@2ndquadrant.com>
> On 28/01/2019 09:14, Kyotaro HORIGUCHI wrote:
> > 0002:
> >
> > The test 54-56 of 001_ssltest.pl failed, which succeeded before
> > applying 0002. Seems to need to use
Andres Freund writes:
> I don't think we are actually contradicting each other. The aim of that
> error was to prevent pieces of code that aren't conditional on
> --with-llvm from including llvmjit.h. I was, for a moment and wrongly,
> thinking that we could style the header in a way that'd make
Hi,
Because of pg_pwrite()[1], openLogOff, a static global variable in xlog.c,
seems taken over by a local variable startoffset and no longer used now.
I write the attached patch that removes openLogOff. Both "make check" and
"make installcheck" passed, and just after that, "pg_ctl -m immediate
On 1/28/19 10:54 PM, Peter Eisentraut wrote:
Or put it at the end?
WITH ctename AS ( query ) MATERIALIZED
Hm, seems like that would be easy to miss for long queries.
Andreas
On Mon, Jan 28, 2019 at 09:58:17PM +, Bossart, Nathan wrote:
> Yes, this simplifies the code quite a bit. I did it this way in
> v6.
Thanks for the quick update. Things could have been made a bit more
simple by just using a for loop instead of while, even if the table
list can be NULL for
On 1/28/19 7:26 PM, Andrey Borodin wrote:
* I am no fan of the tupdesc vs truncTupdesc separation and think that it is a
potential hazard, but I do not have any better suggestion right now.
B-tree is copying tupdesc every time they truncate tuple. We need tuple
truncation a little more often:
Andres Freund writes:
> And even if you, to address Tom's point about plpgsql, had a category
> that could only be thrown by core code,
Actually, that wasn't quite what my point was there. Even if the error
that is thrown is perfectly safe and was thrown from a known spot in the
core code,
On Mon, 28 Jan 2019 at 21:21, Amit Langote
wrote:
> Thanks for the fix, I'll incorporate it in the next version I'll post by
> tomorrow.
I just started reading 0001 again. I made a few notes:
1. Should bms_del_members() instead of bms_difference() if you don't
mind modifying in place, which it
Hi,
On 2019-01-28 17:31:15 -0800, Andres Freund wrote:
> On 2019-01-29 04:17:33 +0300, Alexander Korotkov wrote:
> > I'm probably not yet understanding all the risks this code have. So far I
> > see:
>
> I find these *more* than sufficient to not go to the PG_TRY/CATCH
> approach.
>
>
> > 1)
Alexander Korotkov writes:
> + if (jspThrowErrors(cxt) ||
> + ERRCODE_TO_CATEGORY(errcode) != ERRCODE_DATA_EXCEPTION)
> + PG_RE_THROW();
> BTW, this code also looks... useless. I can't see whole numeric.c
> throwing ERRCODE_DATA_EXCEPTION.
On Tue, Jan 29, 2019 at 4:44 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Tue, Jan 29, 2019 at 4:03 AM Andres Freund wrote:
> >> FWIW, I still think this is a terrible idea and shouldn't be merged this
> >> way. The likelihood of introducing subtle bugs seems way too high - even
> >>
On Tue, Jan 29, 2019 at 4:30 AM Alexander Korotkov
wrote:
> On Tue, Jan 29, 2019 at 4:03 AM Andres Freund wrote:
> > On 2019-01-29 04:00:19 +0300, Alexander Korotkov wrote:
> > > + /*
> > > + * It is safe to use here PG_TRY/PG_CATCH without subtransaction
> > > because
> > > + *
Alexander Korotkov writes:
> On Tue, Jan 29, 2019 at 4:03 AM Andres Freund wrote:
>> FWIW, I still think this is a terrible idea and shouldn't be merged this
>> way. The likelihood of introducing subtle bugs seems way too high - even
>> if it's possibly not buggy today, who says that it's not
Hi,
Although I became your reviewer, it seems to be difficult to feedback in this
CF.
I continue to review, so would you update your patch please?
Until then I review your current patch.
There is one question.
date_1.out which maybe is copy of date.out includes trailing space and gaps of
Hi,
On 2019-01-28 20:21:49 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-01-28 19:51:22 -0500, Tom Lane wrote:
> >> I propose that we should fix this by making the whole bodies of those
> >> two headers be #ifdef USE_LLVM.
>
> > Hm, I think it's sufficient that we error out if llvm
On 2019-01-29 04:17:33 +0300, Alexander Korotkov wrote:
> On Tue, Jan 29, 2019 at 4:03 AM Andres Freund wrote:
> > On 2019-01-29 04:00:19 +0300, Alexander Korotkov wrote:
> > > + /*
> > > + * It is safe to use here PG_TRY/PG_CATCH without subtransaction
> > > because
> > > + * no
On Tue, Jan 29, 2019 at 4:03 AM Andres Freund wrote:
> On 2019-01-29 04:00:19 +0300, Alexander Korotkov wrote:
> > + /*
> > + * It is safe to use here PG_TRY/PG_CATCH without subtransaction
> > because
> > + * no function called inside performs data modification.
> > + */
> >
Andres Freund writes:
> On 2019-01-28 19:51:22 -0500, Tom Lane wrote:
>> I propose that we should fix this by making the whole bodies of those
>> two headers be #ifdef USE_LLVM.
> Hm, I think it's sufficient that we error out if llvm was configured,
> we've sufficient buildfarm machines running
On Tue, Jan 29, 2019 at 4:03 AM Andres Freund wrote:
> On 2019-01-29 04:00:19 +0300, Alexander Korotkov wrote:
> > + /*
> > + * It is safe to use here PG_TRY/PG_CATCH without subtransaction
> > because
> > + * no function called inside performs data modification.
> > + */
> >
Hi,
On 2019-01-29 04:00:19 +0300, Alexander Korotkov wrote:
> + /*
> + * It is safe to use here PG_TRY/PG_CATCH without subtransaction because
> + * no function called inside performs data modification.
> + */
> + PG_TRY();
> + {
> + res =
On 2019-01-28 19:51:22 -0500, Tom Lane wrote:
> On 2019-01-28 11:19:21 -0500, Tom Lane wrote:
> > Since the LLVM stuff went in, src/tools/pginclude/cpluspluscheck
> > fails on my main devel machine, because
> >
> > In file included from /tmp/cpluspluscheck.jobsM6/test.cpp:3:
> >
I wrote:
> Since the LLVM stuff went in, src/tools/pginclude/cpluspluscheck
> fails on my main devel machine, because
Actually, it also fails on another machine that does have LLVM installed:
In file included from /tmp/cpluspluscheck.LqnoZj/test.cpp:3:
./src/include/jit/llvmjit_emit.h: In
Hi,
On 2019-01-28 15:49:33 -0800, Andres Freund wrote:
> On 2019-01-28 18:08:59 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > I'm inclined to put back the
> > >LockBuffer(buf, BUFFER_LOCK_UNLOCK);
> > >LockRelationForExtension(onerel, ExclusiveLock);
> > >
Hi Jesper,
Thanks for updating your patches quickly.
>On 1/28/19 3:50 PM, Peter Eisentraut wrote:
>>> Done, and v4 attached.
>>
>> I would drop the changes in pgupgrade.sgml. We don't need to explain
>> what doesn't happen, when nobody before now ever thought that it would
>> happen.
>>
>>
On Tue, Jan 29, 2019 at 12:37 AM John Naylor
wrote:
>
> On Mon, Jan 28, 2019 at 12:10 PM Amit Kapila wrote:
>
> > 2.
> > @@ -15,13 +15,9 @@
> > SELECT octet_length(get_raw_page('test_rel_forks', 'main', 100)) AS
> > main_100;
> > ERROR: block number 100 is out of range for relation
Hi,
On 2019-01-28 18:08:59 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I'm inclined to put back the
> >LockBuffer(buf, BUFFER_LOCK_UNLOCK);
> >LockRelationForExtension(onerel, ExclusiveLock);
> >UnlockRelationForExtension(onerel, ExclusiveLock);
> >
On 28.01.2019 16:50, Tomas Vondra wrote:
On 1/28/19 1:22 AM, Alexander Korotkov wrote:
* I decided to change behavior of jsonb_path_match() to throw as less
errors as possible. The reason is that it's used to implement
potentially (patch is pending) indexable operator. Index scan is not
Andres Freund writes:
> I'm inclined to put back the
>LockBuffer(buf, BUFFER_LOCK_UNLOCK);
>LockRelationForExtension(onerel, ExclusiveLock);
>UnlockRelationForExtension(onerel, ExclusiveLock);
>LockBufferForCleanup(buf);
>if
Mark Dilger writes:
>> The swtich in src/backend/parser/analyze.c circa line 2819 should
>> probably have an explicit case for RTE_RESULT rather than just a
>> comment and allowing the default to log "unrecognized RTE type",
>> since it's not really unrecognized, just unexpected. But I'm not
>>
Hi,
On 2019-01-28 14:10:55 -0800, Andres Freund wrote:
> So, I'd pushed the latest version. And longfin came back with an
> interesting error:
>
> ERROR: page 135 of relation "pg_class" should be empty but is not
>
> The only way I can currently imagine this happening is that there's a
>
Hi,
So, I'd pushed the latest version. And longfin came back with an
interesting error:
ERROR: page 135 of relation "pg_class" should be empty but is not
The only way I can currently imagine this happening is that there's a
concurrent vacuum that discovers the page is empty, enters it into the
Peter Eisentraut writes:
> On 28/01/2019 21:35, Tom Lane wrote:
>> Conceivably we could make it work without the parens:
>> ...
> Or put it at the end?
> WITH ctename AS ( query ) MATERIALIZED
Yeah, I thought about that too, but it doesn't seem like an improvement.
If the query is very long
On 2019-01-22 11:42:35 -0800, Andres Freund wrote:
> Hi,
>
> On 2019-01-22 11:08:40 -0800, Donald Dong wrote:
> > In the standard_planner, we set the proper JIT flags on the resulting
> > PlannedStmt node. We also offered a planer hook so extensions can
> > add customized planners. The JIT flags
On 28/01/2019 21:35, Tom Lane wrote:
> Conceivably we could make it work without the parens:
>
> WITH ctename AS [ option = value [ , ] ] ( query )
>
> which for the immediate feature I'd be tempted to spell as
>
> WITH ctename AS [ materialize = on/off ] ( query ... )
>
> I
Robert Haas writes:
> On Mon, Jan 28, 2019 at 3:17 PM Tom Lane wrote:
>> I'm really unhappy that force_parallel_mode and
>> parallel_leader_participation are being treated as planner GUCs.
> The only use of parallel_leader_participation at plan time seems to be
> to twiddle the costing, and the
On Fri, Jan 25, 2019 at 04:33:54PM +0200, Heikki Linnakangas wrote:
> On 15/01/2019 02:52, John Naylor wrote:
> >The majority of cases are measurably faster, and the best case is at
> >least 20x faster. On the whole I'd say this patch is a performance win
> >even without further optimization. I'm
On Mon, Jan 28, 2019 at 04:06:17PM +0100, Daniel Verite wrote:
> Michael Paquier wrote:
>
> > In src/bin/psql/copy.c, handleCopyIn():
> >
> > /*
> > * This code erroneously assumes '\.' on a line alone
> > * inside a quoted CSV string terminates the \copy.
> > *
> >
On Fri, Jan 25, 2019 at 01:01:22PM +0100, Daniel Verite wrote:
> Bruce Momjian wrote:
>
> > but I am able to see the failure using STDIN:
> >
> > COPY test FROM STDIN CSV;
> > Enter data to be copied followed by a newline.
> > End with a backslash and a period on a
On Mon, Jan 28, 2019 at 7:32 AM Heikki Linnakangas wrote:
> I spent some time first trying to understand the current algorithm, and
> then rewriting it in a way that I find easier to understand. I came up
> with the attached. I think it optimizes for the same goals as your
> patch, but the
On Sun, Jan 27, 2019 at 10:10:36PM +0900, Michael Paquier wrote:
> On Thu, Jan 24, 2019 at 10:09:30PM -0500, Bruce Momjian wrote:
> > This seems like a bug to me. Looking at the code, psql issues the
> > prompts for STDIN, but when it sees \. alone on a line, it has no idea
> > you are in a
Andres Freund writes:
> On 2019-01-28 13:02:11 -0800, Andres Freund wrote:
>> It's not required by C99, it however is required by C11. But a lot of
>> compilers have allowed it as an extension for a long time (like before
>> C99), unless suppressed by some option.
> Hm, it's only in gcc 4.6, so
Andres Freund writes:
> On 2019-01-28 15:50:22 -0500, Tom Lane wrote:
>> Andres Freund writes:
>>> Ugh, isn't it nicer to just use the underlying struct type instead of
>>> that?
>> No, because that'd mean that anyplace relying on optimizer.h would also
>> have to write "struct PlannerInfo"
Hi,
On 2019-01-15 17:35:21 -0500, Tom Lane wrote:
> Andres Freund writes:
> >> Looking at the surrounding code made me wonder about the wisdom of
> >> entering empty pages as all-visible and all-frozen into the VM. That'll
> >> mean we'll never re-discover them on a primary, after promotion.
Hi,
Bruce Momjian writes:
> It is nice it is a smaller patch. Please remind me of the performance
> advantages of this patch.
The patch as it stands is mostly helpful in those situations:
- application server(s) start e.g. 2000 connections at start-up and
then use them depending on user
On 03/11/2018 00:14, Andreas 'ads' Scherbaum wrote:
> GNU make, version 3.8 or newer
> ISO/ANSI C compilar (at least C99-compliant)
> Flex 2.5.31 or later, and Bison 1.875 or later (for building from git)
> Perl 5.8.3 (for building from git)
I'm not in favor of listing all these versions here.
Hi,
On 2019-01-28 13:02:11 -0800, Andres Freund wrote:
> It's not required by C99, it however is required by C11. But a lot of
> compilers have allowed it as an extension for a long time (like before
> C99), unless suppressed by some option. I think that's partially because
> C++ has allowed it
On Thu, Jan 24, 2019 at 08:14:41PM +0300, Konstantin Knizhnik wrote:
> The main differences with pgbouncer are that:
>
> 1. It is embedded and requires no extra steps for installation and
> configurations.
> 2. It is not single threaded (no bottleneck)
> 3. It supports all clients (if client
Hi,
On 2019-01-28 15:50:22 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-01-28 15:17:19 -0500, Tom Lane wrote:
> >> Since I was intentionally trying to limit what optimizer.h pulls in,
> >> and in particular not let it include relation.h, I needed an opaque
> >> typedef for
On 1/28/19 3:50 PM, Peter Eisentraut wrote:
Done, and v4 attached.
I would drop the changes in pgupgrade.sgml. We don't need to explain
what doesn't happen, when nobody before now ever thought that it would
happen.
Also, we don't need the versioning stuff. The new cluster in pg_upgrade
is
On 28/01/2019 17:47, Jesper Pedersen wrote:
> On 1/28/19 11:30 AM, Fabrízio de Royes Mello wrote:
>> IMHO you should use long option name '--jobs' like others.
>>
>
> Thanks for your feedback !
>
> Done, and v4 attached.
I would drop the changes in pgupgrade.sgml. We don't need to explain
what
Andres Freund writes:
> On 2019-01-28 15:17:19 -0500, Tom Lane wrote:
>> Since I was intentionally trying to limit what optimizer.h pulls in,
>> and in particular not let it include relation.h, I needed an opaque
>> typedef for PlannerInfo. On the other hand relation.h also needs to
>> typedef
Robert Haas writes:
> However, generally we have not had great luck with just sticking
> keywords in there (cf. VACUUM, ANALYZE, EXPLAIN, COPY) which is why I
> suggested using a flexible syntax with parenthesized options.
Fair, except that as you then proceed to point out, that does not work
On Mon, Jan 28, 2019 at 3:17 PM Tom Lane wrote:
> I'm really unhappy that force_parallel_mode and
> parallel_leader_participation are being treated as planner GUCs.
> They are not that, IMO, because they also affect the behavior of
> the executor, cf HandleParallelMessage, ExecGather,
Hi,
On 2019-01-28 15:17:19 -0500, Tom Lane wrote:
> In <6044.1548524...@sss.pgh.pa.us> I worried about how much planner
> stuff that patch might end up dragging into files that contain
> planner support functions, and suggested that we could refactor the
> planner's header files to reduce the
> Otherwise "\g -" looks good as a portable solution.
+1
In <6044.1548524...@sss.pgh.pa.us> I worried about how much planner
stuff that patch might end up dragging into files that contain
planner support functions, and suggested that we could refactor the
planner's header files to reduce the inclusion footprint. Attached
are some proposed patches to
On Fri, Jan 25, 2019 at 7:21 PM Tom Lane wrote:
> Anyway I think the names need to be any-something.
To me, that seems unnecessarily rigid. Not a bad idea if we can come
up with something that is otherwise acceptable. But all of your
suggestions sound worse than Pavel's proposal, so...
--
On Mon, Jan 28, 2019 at 12:10 PM Amit Kapila wrote:
>
> On Mon, Jan 28, 2019 at 10:03 AM John Naylor
> wrote:
> >
> 1.
> @@ -26,7 +26,7 @@
> pg_relation_size('fsm_check_size', 'fsm') AS fsm_size;
> heap_size | fsm_size
> ---+--
> - 24576 |0
> + 32768 |
On Sun, Jan 27, 2019 at 8:23 AM Andrew Gierth
wrote:
> I think it makes more sense to say
> that we never inline if MATERIALIZED is specified, that we always inline
> if NOT MATERIALIZED is specified, and that if neither is specified the
> planner will choose (but perhaps note that currently it
On Mon, Jan 21, 2019 at 10:28 AM Tom Lane wrote:
> Andreas Karlsson writes:
> > I have a minor biksheddish question about the syntax.
> > You proposed:
> > WITH cte_name [[NOT] MATERIALIZED] AS (query) main_query
> > While Andrew proposed:
> > WITH cte_name AS [[NOT] MATERIALIZED] (query)
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Mon, Jan 28, 2019 at 7:26 PM Tom Lane wrote:
>
> > Stephen Frost writes:
> > >> On Sun, Jan 27, 2019 at 2:28 AM Noah Misch wrote:
> > >>> What are those blocked infrastructure improvements?
> >
> > > The specific improvements
On Mon, Jan 28, 2019 at 7:26 PM Tom Lane wrote:
> Stephen Frost writes:
> >> On Sun, Jan 27, 2019 at 2:28 AM Noah Misch wrote:
> >>> What are those blocked infrastructure improvements?
>
> > The specific improvements we're talking about are DKIM/DMARC/SPF, which
> > is becoming more and more
Thank you very much for reviewing the patch!
> 28 янв. 2019 г., в 12:15, Andreas Karlsson написал(а):
>
> = Code
>
> * Have some minor style issues like that there should be spaces around || (in
> gistcanreturn()) and ? and : (in gistFormTuple()).
Fixed.
>
> * I do not see any need for
Stephen Frost writes:
>> On Sun, Jan 27, 2019 at 2:28 AM Noah Misch wrote:
>>> What are those blocked infrastructure improvements?
> The specific improvements we're talking about are DKIM/DMARC/SPF, which
> is becoming more and more important to making sure that the email from
> our lists can
On Sunday, January 13, 2019 4:57:48 PM EST Tom Lane wrote:
> I also wonder why we'd allow RECORD but not RECORDARRAY.
That's by omission. There's no reason to refuse RECORDARRAY here for
the same reason why RECORD is accepted.
> More generally, why not any polymorphic type? [...] the
> fact
Robert Haas writes:
> On Sat, Jan 26, 2019 at 12:35 PM Tom Lane wrote:
>> Attached is an 0004 that makes a stab at providing some intelligence
>> for unnest() and the integer cases of generate_series().
> That looks awesome.
> I'm somewhat dubious about whole API. It's basically -- if you
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sun, Jan 27, 2019 at 2:28 AM Noah Misch wrote:
> > > Does this also implicitly mean we've just agreed to push back the
> > > retirement of the @postgresql.org aliases for the lists until v11 is
> > > EOL..?
> > >
> > > I can understand
On Mon, Jan 28, 2019 at 10:18 AM Tom Lane wrote:
> In the pluggable-storage discussion, there was some talk of renaming
> nodes/relation.h to avoid confusion with the new access/relation.h
> header. I think this is a fine idea, not only because of that conflict
> but because "relation.h" has
On 1/28/19 11:30 AM, Fabrízio de Royes Mello wrote:
IMHO you should use long option name '--jobs' like others.
Thanks for your feedback !
Done, and v4 attached.
Best regards,
Jesper
>From 142b4723f433f39d0eed2ced4beccc3721451103 Mon Sep 17 00:00:00 2001
From: jesperpedersen
Date: Fri, 21
On Sat, Jan 26, 2019 at 12:35 PM Tom Lane wrote:
> Attached is an 0004 that makes a stab at providing some intelligence
> for unnest() and the integer cases of generate_series().
That looks awesome.
I'm somewhat dubious about whole API. It's basically -- if you have a
problem and a PhD in
On Sun, Jan 27, 2019 at 2:28 AM Noah Misch wrote:
> > Does this also implicitly mean we've just agreed to push back the
> > retirement of the @postgresql.org aliases for the lists until v11 is
> > EOL..?
> >
> > I can understand the concern around translators and back-patching and
> > such, but I
On Mon, Jan 28, 2019 at 1:15 PM Jesper Pedersen
wrote:
>
> Done.
>
> Attached is v3.
>
IMHO you should use long option name '--jobs' like others.
Regards,
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e
Since the LLVM stuff went in, src/tools/pginclude/cpluspluscheck
fails on my main devel machine, because
In file included from /tmp/cpluspluscheck.jobsM6/test.cpp:3:
./src/include/jit/llvmjit_emit.h:13:25: error: llvm-c/Core.h: No such file or
directory
and then there's a bunch of ensuing
On Fri, Jan 25, 2019 at 4:18 PM Alvaro Herrera wrote:
> Right, the planner/executor "disconnect" is one of the challenges, and
> why I was trying to keep the old copy of the PartitionDesc around
> instead of building updated ones as needed.
I agree that would be simpler, but I just don't see how
Tom Lane wrote:
> > Now as far as I can see, there is nothing that \copy to file or program
> > can do that COPY TO STDOUT cannot do.
>
> I don't think there's a way to get the effect of "\copy to pstdout"
> (which, IIRC without any caffeine, means write to psql's stdout regardless
> of
On 09/01/2019 02:47, Peter Geoghegan wrote:
On Fri, Dec 28, 2018 at 3:32 PM Peter Geoghegan wrote:
On Fri, Dec 28, 2018 at 3:20 PM Heikki Linnakangas wrote:
I'm envisioning that you have an array, with one element for each item
on the page (including the tuple we're inserting, which isn't
"Daniel Verite" writes:
> Tom Lane wrote:
>> A variant that might or might not be safer is "\g > insist on you putting a mark there that shows you intended to read.
> I haven't written any patch yet, but I was thinking of submitting
> something like that, with the addition of "\g >foo" as
On Tue, Jan 29, 2019 at 12:18 AM Tom Lane wrote:
> In the pluggable-storage discussion, there was some talk of renaming
> nodes/relation.h to avoid confusion with the new access/relation.h
> header. I think this is a fine idea, not only because of that conflict
> but because "relation.h" has
Tom Lane wrote:
> A variant that might or might not be safer is "\g insist on you putting a mark there that shows you intended to read.
>
> Also, not quite clear what we'd do about copy-from-program.
> I think "\g |foo" is definitely confusing for that. "\g foo|"
> would be better if it
1 - 100 of 124 matches
Mail list logo
