On Wed, Apr 12, 2017 at 10:44 PM, Andrew Borodin wrote:
>> How do you think we should proceed? Which projects do you think should
>> eventually be in core, versus which are fine as extensions?
>
> Some points in favor of Range joins via nbtree:
My patch doesn't require
I'd like to put a supplimentary explanation.
At Tue, 11 Apr 2017 17:38:12 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170411.173812.133964522.horiguchi.kyot...@lab.ntt.co.jp>
> Sorry, what I have just sent was broken.
>
> At Tue, 11 Apr 2017
On Thu, Apr 13, 2017 at 12:36 PM, Michael Paquier
wrote:
> On Thu, Apr 13, 2017 at 12:28 PM, Fujii Masao wrote:
>> On Thu, Apr 13, 2017 at 5:25 AM, Peter Eisentraut
>> wrote:
>>> On 4/12/17 09:55, Fujii Masao
On 13/04/17 13:01, Kyotaro HORIGUCHI wrote:
> Ouch! I replied to wrong mail.
>
> At Thu, 13 Apr 2017 19:55:04 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> wrote in
> <20170413.195504.89348773.horiguchi.kyot...@lab.ntt.co.jp>
>> I confused sync and apply
On Thu, Apr 13, 2017 at 9:13 PM, Bruce Momjian wrote:
> On Thu, Apr 13, 2017 at 09:02:27PM +0200, Magnus Hagander wrote:
> > On Thu, Apr 13, 2017 at 12:30 AM, Peter Eisentraut <
> > peter.eisentr...@2ndquadrant.com> wrote:
> >
> > On 4/10/17 11:30, Magnus Hagander wrote:
>
On Thu, Apr 6, 2017 at 3:14 AM, Amit Langote
wrote:
>> The bulk of operations that work on traditional tables also work on
>> partitions
>> and partitioned tables. The next closest kind of relation, a materialized
>> view, is far less table-like. Therefore, I
On 2017-04-13 16:34:12 -0400, Robert Haas wrote:
> On Thu, Mar 16, 2017 at 4:45 AM, Andres Freund wrote:
> > During citus development we noticed that restrictions aren't pushed down
> > into lateral subqueries, even if they semantically could. For example,
> > in this dumbed
On 04/13/2017 01:31 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Thu, Apr 6, 2017 at 4:05 PM, Rod Taylor wrote:
>> > I'm a little confused on why a SELECT policy fires against the NEW record
>> > for an UPDATE when using multiple FOR
On Thu, Apr 13, 2017 at 09:02:27PM +0200, Magnus Hagander wrote:
> On Thu, Apr 13, 2017 at 12:30 AM, Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote:
>
> On 4/10/17 11:30, Magnus Hagander wrote:
> > After you've run pg_upgrade, you have to loop through all your databases
>
Hi,
Though I've read only a part of the logical rep code yet, I'd like to
share some (relatively minor) review comments that I got so far.
In ApplyWorkerMain(), DatumGetInt32() should be used to get integer
value from the argument, instead of DatumGetObjectId().
No one resets
On Thu, Mar 16, 2017 at 4:45 AM, Andres Freund wrote:
> During citus development we noticed that restrictions aren't pushed down
> into lateral subqueries, even if they semantically could. For example,
> in this dumbed down example:
>
> postgres[31776][1]=# CREATE TABLE
On 2017-04-13 14:05:43 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-04-13 12:56:14 -0400, Tom Lane wrote:
> >> Andres Freund writes:
> >>> Cool. I wonder if we also should remove AtEOXact_CatCache()'s
> >>> cross-checks - the resowner
Andres Freund writes:
> On 2017-04-13 12:56:14 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> Cool. I wonder if we also should remove AtEOXact_CatCache()'s
>>> cross-checks - the resowner replacement has been in place for a while,
>>> and seems
On Thu, Apr 13, 2017 at 3:48 PM, Magnus Hagander wrote:
>> Well, pg_upgrade creates ./analyze_new_cluster.sh, but that just
>> contains:
>>
>> "/u/pgsql/bin/vacuumdb" --all --analyze-in-stages
>>
>> Seems like we should just get rid of ./analyze_new_cluster.sh and
>
>
> > I suggest to reuse pgbench expression engine, developed by Haas Robert:-)
>
> Not a bad idea (though I'm sure there are other reasonable options, too).
>
>
I don't want to stand in the way of any progress in getting expressions
into \if and some subspecies of \set. But, assuming we don't
On Thu, Apr 13, 2017 at 9:23 PM, Masahiko Sawada wrote:
> On Thu, Apr 13, 2017 at 5:17 PM, Kyotaro HORIGUCHI
> wrote:
>> Hello,
>>
>> At Thu, 6 Apr 2017 16:17:31 +0900, Masahiko Sawada
>> wrote in
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Apr 6, 2017 at 4:05 PM, Rod Taylor wrote:
> > I'm a little confused on why a SELECT policy fires against the NEW record
> > for an UPDATE when using multiple FOR policies. The ALL policy doesn't seem
> > to have that
On Fri, Mar 17, 2017 at 7:57 AM, Yugo Nagata wrote:
> I also understanded that my design has a problem during pg_dump and
> pg_upgrade, and that some information to identify the partition
> is required not depending the command order. However, I feel that
> Amul's design is a
On Thu, Apr 6, 2017 at 4:05 PM, Rod Taylor wrote:
> I'm a little confused on why a SELECT policy fires against the NEW record
> for an UPDATE when using multiple FOR policies. The ALL policy doesn't seem
> to have that restriction.
My guess is that you have found a bug.
--
On Mon, Apr 3, 2017 at 3:32 PM, Daniel Verite wrote:
> In interactive mode, the warning in untaken branches is misleading
> when \endif is on the same line as the commands that
> are skipped. For instance:
>
> postgres=# \if false \echo NOK \endif
> \echo command
Hello,
I didn't realize that my target_session_attrs naming proposal was committed. I
didn't think half way it would be adopted, because the name is less intuitive
than the original target_server_type, and is different from the PgJDBC's
targetServerType.
From:
On 13 April 2017 at 09:27, Amit Langote wrote:
> Attached patch modifies a sentence in the inval.c header comment to
> mention that operations on a pg_index tuple also registers relcache flush
> operation.
Correctly observed. Patch pushed.
--
Simon Riggs
Hi.
I got errors of patching on CentOS 7:
bash-4.2$ grep Hunk *.log | grep FAILED
0005-hj-leader-gate-v11.patch.log:Hunk #1 FAILED at 14.
0010-hj-parallel-v11.patch.log:Hunk #2 FAILED at 2850.
0010-hj-parallel-v11.patch.log:Hunk #1 FAILED at 21.
0010-hj-parallel-v11.patch.log:Hunk #3 FAILED at
I wonder if trying to add a relation to a publication that it is already a
part should be considered a no-op, instead of causing an error (which
happens in the ALTER PUBLICATION ADD TABLES case).
create table bar (a int);
create publication mypub for table bar;
alter publication mypub add table
2017-04-13 11:30 GMT+05:00 Jeff Davis :
> I don't quite follow. I don't think any of these proposals uses btree,
> right? Range merge join doesn't need any index, your proposal uses
> gist, and PgSphere's crossmatch uses gist.
Merge join will use presorted data, B-tree provides
On 2017/04/13 18:09, Simon Riggs wrote:
> On 13 April 2017 at 09:27, Amit Langote wrote:
>> Attached patch modifies a sentence in the inval.c header comment to
>> mention that operations on a pg_index tuple also registers relcache flush
>> operation.
>
> Correctly
Hello,
At Thu, 6 Apr 2017 16:17:31 +0900, Masahiko Sawada
wrote in
On 4/4/17, Peter Eisentraut wrote:
> On 3/30/17 22:47, Vitaly Burovoy wrote:
>> It seemed not very hard to fix it.
>> Please find attached patch to be applied on top of your one.
>>
>> I've added more tests to cover different cases of changing bounds when
>> data
On 4/6/17, Vitaly Burovoy wrote:
> On 4/6/17, Peter Eisentraut wrote:
>> As I tried to mention earlier, it is very difficult to implement the IF
>> NOT EXISTS behavior here, because we need to run the commands the create
>> the sequence
On 13 April 2017 at 14:59, Tsunakawa, Takayuki
wrote:
> 2. Make transaction_read_only GUC_REPORT
> This is to avoid the added round-trip by SHOW command. It also benefits
> client apps that want to know when the server gets promoted? And this may
> simplify
Attached patch modifies a sentence in the inval.c header comment to
mention that operations on a pg_index tuple also registers relcache flush
operation.
Thanks,
Amit
diff --git a/src/backend/utils/cache/inval.c b/src/backend/utils/cache/inval.c
index 8159ab340d..9d62544554 100644
---
On Thu, Apr 13, 2017 at 2:40 AM, Andres Freund wrote:
> On 2017-04-12 20:15:52 -0400, Peter Eisentraut wrote:
> > On 4/11/17 05:15, Magnus Hagander wrote:
> > > Is there a particular reason we don't have a function to *set* the
> > > restart_lsn of a replication slot, other
At Thu, 13 Apr 2017 13:52:40 +0900, Michael Paquier
wrote in
> On Tue, Apr 11, 2017 at 5:38 PM, Kyotaro HORIGUCHI
> wrote:
> > Sorry, what I have just sent was
On Thu, Apr 13, 2017 at 11:53 AM, Masahiko Sawada wrote:
> On Wed, Apr 12, 2017 at 11:46 PM, Peter Eisentraut
> wrote:
>> On 4/12/17 00:48, Masahiko Sawada wrote:
>>> On Wed, Apr 12, 2017 at 1:28 PM, Peter Eisentraut
Perhaps instead
On Fri, Apr 14, 2017 at 6:32 AM, Pierre Ducroquet wrote:
> Yesterday while doing a few pg_basebackup, I realized that the integer
> parameters were not properly checked against invalid input.
> It is not a critical issue, but this could be misleading for an user who
> writes
On Fri, Apr 14, 2017 at 2:47 AM, Fujii Masao wrote:
> I'm thinking that it's less confusing to report always 0 as the priority of
> async standby whatever the setting of synchronous_standby_names is.
> Thought?
Or we could have priority being reported to NULL for async
On Thu, Apr 13, 2017 at 7:40 PM, Vitaly Burovoy
wrote:
> On 4/6/17, Vitaly Burovoy wrote:
>> On 4/6/17, Peter Eisentraut wrote:
>>> As I tried to mention earlier, it is very difficult to implement the IF
>>>
Hi
Yesterday while doing a few pg_basebackup, I realized that the integer
parameters were not properly checked against invalid input.
It is not a critical issue, but this could be misleading for an user who
writes -z max or -s 0.5…
I've attached the patch to this mail. Should I add it to the next
On Fri, Apr 14, 2017 at 9:38 AM, Michael Paquier
wrote:
> On Fri, Apr 14, 2017 at 2:47 AM, Fujii Masao wrote:
>> I'm thinking that it's less confusing to report always 0 as the priority of
>> async standby whatever the setting of
On 2017/04/14 5:28, Robert Haas wrote:
> On Thu, Apr 6, 2017 at 3:14 AM, Amit Langote
> wrote:
>>> The bulk of operations that work on traditional tables also work on
>>> partitions
>>> and partitioned tables. The next closest kind of relation, a materialized
>>>
Rod, all,
* Joe Conway (m...@joeconway.com) wrote:
> On 04/13/2017 01:31 PM, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> On Thu, Apr 6, 2017 at 4:05 PM, Rod Taylor wrote:
> >> > I'm a little confused on why a SELECT policy fires against the
On 12/04/17 06:10, Peter Eisentraut wrote:
> On 3/24/17 10:49, Petr Jelinek wrote:
>> Rebase after table copy patch got committed.
>
> You could please sent another rebase of this, perhaps with some more
> documentation, as discussed downthread.
>
> Also, I wonder why we don't offer the other
Hello Robert,
Calling the server is already available:
SELECT AS varname \gset
Sure, but people are going to want to do it inline with the \if.
Yes... and my changed opinion is that the answer to this approach should
be "no", only client side after if.
Anything that can be done
On Mon, Apr 3, 2017 at 3:32 PM, Daniel Verite wrote:
In interactive mode, the warning in untaken branches is misleading
when \endif is on the same line as the commands that
are skipped. For instance:
postgres=# \if false \echo NOK \endif
\echo command ignored;
On 13/04/17 12:23, Masahiko Sawada wrote:
> On Thu, Apr 13, 2017 at 11:53 AM, Masahiko Sawada
> wrote:
>> On Wed, Apr 12, 2017 at 11:46 PM, Peter Eisentraut
>> wrote:
>>> On 4/12/17 00:48, Masahiko Sawada wrote:
On Wed, Apr 12, 2017
On Fri, Apr 14, 2017 at 3:03 AM, Fujii Masao wrote:
> On Thu, Apr 13, 2017 at 12:36 PM, Michael Paquier
> wrote:
>> On Thu, Apr 13, 2017 at 12:28 PM, Fujii Masao wrote:
>>> On Thu, Apr 13, 2017 at 5:25 AM, Peter Eisentraut
On 13/04/17 18:11, Robert Haas wrote:
> On Thu, Apr 13, 2017 at 12:05 PM, Peter Eisentraut
> wrote:
>> On 4/12/17 18:31, Peter Eisentraut wrote:
>>> On 4/11/17 23:41, Noah Misch wrote:
On Tue, Apr 11, 2017 at 11:21:24PM -0400, Peter Eisentraut wrote:
>
On 4/13/17 12:11, Robert Haas wrote:
> I wonder if we should have an --no-subscriptions option, now that they
> are dumped by default, just like we have --no-blobs, --no-owner,
> --no-password, --no-privileges, --no-acl, --no-tablespaces, and
> --no-security-labels. It seems like there is
Thanks for looking at this!
On 13/04/17 02:29, Andres Freund wrote:
> Hi,
> On 2017-03-03 01:30:11 +0100, Petr Jelinek wrote:
>
>> From 7d5b48c8cb80e7c867b2096c999d08feda50b197 Mon Sep 17 00:00:00 2001
>> From: Petr Jelinek
>> Date: Fri, 24 Feb 2017 21:39:03 +0100
>>
On 13/04/17 07:02, Andres Freund wrote:
>
> On April 12, 2017 9:58:12 PM PDT, Noah Misch wrote:
>> On Wed, Apr 12, 2017 at 10:21:51AM -0700, Andres Freund wrote:
>>> On 2017-04-12 11:03:57 -0400, Peter Eisentraut wrote:
On 4/12/17 02:31, Noah Misch wrote:
>>> But I
On Thu, Apr 13, 2017 at 6:06 PM, Robert Haas wrote:
> On Thu, Apr 13, 2017 at 11:48 AM, Peter Eisentraut
> wrote:
> > On 4/12/17 22:56, Bruce Momjian wrote:
> >> Is pg_upgrade the right place for an extension upgrade script? When
> >>
>
> > I suggest to reuse pgbench expression engine, developed by Haas Robert:-)
>
> Not a bad idea (though I'm sure there are other reasonable options, too).
>
I checked the pgbench code - and I think it can work well - just add
logical operators and compare operators.
Don't need to create more
2017-04-13 19:46 GMT+02:00 Corey Huinker :
>
>> > I suggest to reuse pgbench expression engine, developed by Haas
>> Robert:-)
>>
>> Not a bad idea (though I'm sure there are other reasonable options, too).
>>
>>
> I don't want to stand in the way of any progress in
On Thu, Apr 13, 2017 at 12:30 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 4/10/17 11:30, Magnus Hagander wrote:
> > After you've run pg_upgrade, you have to loop through all your databases
> > and do an "ALTER EXTENSION abc UPDATE" once for each extension.
> >
> > Is
On Thu, Apr 13, 2017 at 9:33 PM, Tom Lane wrote:
> Amit Langote writes:
>> I wonder if trying to add a relation to a publication that it is already a
>> part should be considered a no-op, instead of causing an error (which
>> happens in the
Sorry for the too-brief reply.
At Tue, 11 Apr 2017 20:08:46 +0300, Konstantin Knizhnik
wrote in
<94c8692a-f299-b72b-6227-270b8a9ed...@postgrespro.ru>
>
> On 04.04.2017 13:29, Kyotaro HORIGUCHI wrote:
> > Hi,
> >
> > At Sun, 02 Apr 2017 16:30:24 +0300, Konstantin
Tomas Vondra wrote:
> On 04/10/2017 12:12 PM, David Rowley wrote:
> > During my review and time spent working on the functional dependencies
> > part of extended statistics I wondered what was the use for the
> > pg_stats_ext view. I was unsure why the length of the serialised
> > dependencies was
On 2017/04/14 10:57, Petr Jelinek wrote:
> I don't think inheritance and partitioning should behave the same in
> terms of logical replication.
I see.
>
> For me the current behavior with inherited tables is correct.
OK.
By the way, what do you think about the pg_dump example/issue I
Hi Stephen,
On 2017/04/14 0:05, Stephen Frost wrote:
> Robert,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
>> So I think I was indeed confused before, and I think you're basically
>> right here, but on one point I think you are not right -- ALTER TABLE
>> ONLY .. CHECK () doesn't work on a
On Mon, Apr 10, 2017 at 09:39:22PM +1200, David Rowley wrote:
> While reviewing extended stats I noticed that it was possible to
> create extended stats on many object types, including sequences. I
> mentioned that this should be disallowed. Statistics were then changed
> to be only allowed on
On Fri, Apr 14, 2017 at 1:37 AM, Heikki Linnakangas wrote:
> On 04/13/2017 05:53 AM, Michael Paquier wrote:
>> +* Parse the list of SASL authentication mechanisms in the
>> +* AuthenticationSASL message, and select the best mechanism that we
>> +* support. (Only
Heikki Linnakangas writes:
> I'm talking about the code that reads a bunch of from each tape, loading
> them into the memtuples array. That code was added by Tom Lane, back in
> 1999:
> commit cf627ab41ab9f6038a29ddd04dd0ff0ccdca714e
> Author: Tom Lane
>
On Thu, Apr 13, 2017 at 10:19 PM, Peter Geoghegan wrote:
> I actually think Heikki's work here would particularly help on
> spinning rust, especially when less memory is available. He
> specifically justified it on the basis of it resulting in a more
> sequential read pattern,
On 4/4/17 09:59, Stephen Frost wrote:
>> Attached is a patch that adds the pg_dump support, but I'm struggling to
>> make the tests work. Could you take a look? Problem one I'm seeing is
>> that the tests assert that there are no comments in the post-data
>> section, which is no longer the case
On 3/29/17 04:11, Alexander Law wrote:
> Please consider committing the attached patches to remove trailing
> spaces in strings in the source code.
> One patch is for localizable messages, and the other is just for
> consistency (less important).
committed
--
Peter Eisentraut
On Thu, Apr 13, 2017 at 7:35 AM, David Rowley
wrote:
> On 13 April 2017 at 11:22, Peter Eisentraut
> wrote:
>> Is this patch considered ready for review as a backpatch candidate?
>
> Yes, however, the v5 patch is based on master.
I wrote:
> Heikki Linnakangas writes:
>> I'm talking about the code that reads a bunch of from each tape, loading
>> them into the memtuples array. That code was added by Tom Lane, back in
>> 1999:
>> So apparently there was a benefit back then, but is it still worthwhile?
>
On Thu, Apr 06, 2017 at 10:26:16PM -0700, Vitaly Burovoy wrote:
> On 4/6/17, Peter Eisentraut wrote:
> > On 4/4/17 22:53, Vitaly Burovoy wrote:
> >> The next nitpickings to the last patch. I try to get places with
> >> lacking of variables' initialization.
> >>
I don't think inheritance and partitioning should behave the same in
terms of logical replication.
For me the current behavior with inherited tables is correct.
What I would like partitioned tables support to look like is that if we
add partitioned table, the data decoded from any of the
On Thu, Apr 13, 2017 at 9:51 PM, Tom Lane wrote:
> I'm fairly sure that the point was exactly what it said, ie improve
> locality of access within the temp file by sequentially reading as many
> tuples in a row as we could, rather than grabbing one here and one there.
>
> It
On Wed, Apr 05, 2017 at 01:43:42PM -0400, Peter Eisentraut wrote:
> On 4/5/17 02:56, Noah Misch wrote:
> > On Thu, Mar 23, 2017 at 11:21:39PM -0400, Peter Eisentraut wrote:
> >> I think the fix belongs into the web site CSS, so there is nothing to
> >> commit into PostgreSQL here. I will close
On Thu, Apr 13, 2017 at 10:04 PM, Oleg Golovanov wrote:
> bash-4.2$ grep Hunk *.log | grep FAILED
> 0005-hj-leader-gate-v11.patch.log:Hunk #1 FAILED at 14.
> 0010-hj-parallel-v11.patch.log:Hunk #2 FAILED at 2850.
> 0010-hj-parallel-v11.patch.log:Hunk #1 FAILED at 21.
>
On 2017/04/13 0:10, Robert Haas wrote:
> On Wed, Apr 5, 2017 at 8:25 AM, Peter Eisentraut
> wrote:
>> After thinking about it some more, I think the behavior we want would be
>> that changes to inheritance would reflect in the publication membership.
>> So if
I confused sync and apply workers.
sync worker failure at start causes immediate retries.
At Thu, 13 Apr 2017 11:53:27 +0900, Masahiko Sawada
wrote in
> On Wed, Apr 12, 2017 at 11:46 PM, Peter Eisentraut
On Thu, Apr 13, 2017 at 5:17 PM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Thu, 6 Apr 2017 16:17:31 +0900, Masahiko Sawada
> wrote in
Aleksander,
> What you actually meant probably was "do so on ALL standby servers
> first", right?
Good point, right now it can give you the idea that applying it to just
1 standby (instead of all of them) is good enough, when instead you
need to apply it to all of them.
Attached is an adjusted
Hello Robert,
My 0.02€ about your interesting questions and points.
On Sun, Apr 2, 2017 at 3:56 PM, Tom Lane wrote:
So my view of this is that "send the expression to the server" ought
to be just one option for \if, not the only way to do it.
I heartily agree. There
Ouch! I replied to wrong mail.
At Thu, 13 Apr 2017 19:55:04 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170413.195504.89348773.horiguchi.kyot...@lab.ntt.co.jp>
> I confused sync and apply workers.
> sync worker failure at start causes immediate
Amit Langote writes:
> I wonder if trying to add a relation to a publication that it is already a
> part should be considered a no-op, instead of causing an error (which
> happens in the ALTER PUBLICATION ADD TABLES case).
On what grounds?
The equivalent case for
On 04/13/2017 03:28 PM, Tom Lane wrote:
Tomas Vondra writes:
On 04/12/2017 03:36 PM, David Rowley wrote:
"stakind" seems like a better name. I'd have personally gone with
"statype" but pg_statistic already thinks stakind is better.
+1 to stakind
I agree with
On 04/13/2017 02:35 PM, Álvaro Hernández Tortosa wrote:
On 13/04/17 13:24, Heikki Linnakangas wrote:
Right, when we get channel binding, the server will list
"SCRAM-SHA-256" and "SCRAM-SHA-256-PLUS" as the list of mechanisms.
And if we get channel binding using something else than tls-unique,
Tomas Vondra writes:
> On 04/12/2017 03:36 PM, David Rowley wrote:
>> "stakind" seems like a better name. I'd have personally gone with
>> "statype" but pg_statistic already thinks stakind is better.
> +1 to stakind
I agree with that, but as long as we're
On 04/13/2017 05:54 AM, Michael Paquier wrote:
On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa
wrote:
By looking at the them, and unless I'm missing something, I don't see
how the extra information for the future implementation of channel binding
would be added
On 13/04/17 13:24, Heikki Linnakangas wrote:
On 04/13/2017 05:54 AM, Michael Paquier wrote:
On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa
wrote:
By looking at the them, and unless I'm missing something, I
don't see
how the extra information for the future
On 13/04/17 04:54, Michael Paquier wrote:
On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa
wrote:
By looking at the them, and unless I'm missing something, I don't see
how the extra information for the future implementation of channel binding
would be added
My only desire would be to have a final spec and implement the full parser
now, not have to change it in the future. We already know today all the
requirements, so please pick one and I will follow it :)
On Apr 13, 2017 13:47, "Heikki Linnakangas" wrote:
> On 04/13/2017 02:35
On Thu, Apr 13, 2017 at 11:05 AM, Stephen Frost wrote:
> Sure, though I won't be able to today and I've got some doubts about the
> other patches. I'll have more time tomorrow though.
OK, cool. I'll mark you down as the owner on the open items list.
--
Robert Haas
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> So I think I was indeed confused before, and I think you're basically
> right here, but on one point I think you are not right -- ALTER TABLE
> ONLY .. CHECK () doesn't work on a table with inheritance children
> regardless of whether the
Arjen Nienhuis wrote:
> Hi,
>
> In the devel docs for xmltable there should be a comma after XMLNAMESPACES()
Thanks, pushed.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing
Arjen Nienhuis wrote:
> It wasn't completely clear for me how to use namespaces in xmltable().
> Maybe add this to the documentation. It shows the default namespace
> and quoting the namespace name.
Thanks, pushed.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL
Pavel Stehule wrote:
> Hi
>
> When I tested XMLTABLE function I found a bug of XPATH function -
> xpath_internal
>
> There xmltype is not correctly encoded to xmlChar due possible invalid
> encoding info in header. It is possible when XML was loaded with recv
> function and has not UTF8
On 4/12/17 22:56, Bruce Momjian wrote:
> Is pg_upgrade the right place for an extension upgrade script? When
> pg_upgrade started creating an incremental-analyze script, people
> thought it should be more generic so it was moved to vacuumdb
> --analyze-in-stages. Seems we should do the same
Pavel Stehule wrote:
> Hi
>
> I am sending a patch with changes in XMLTABLE documentation proposed by
> Arjen.
Thanks, pushed with some rewording.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via
On 04/13/2017 05:53 AM, Michael Paquier wrote:
Thanks for the updated patches! I had a close look at them.
Let's begin with 0001...
/*
* Negotiation generated data to be sent to the client.
*/
- elog(DEBUG4, "sending SASL response token of length
On 2017-04-13 12:13:30 -0400, Tom Lane wrote:
> Andreas Karlsson writes:
> > Here is my proof of concept patch. It does basically the same thing as
> > Andres's patch except that it handles quoted values a bit better and
> > does not try to support anything other than the
On Wed, Apr 12, 2017 at 6:58 PM, Andres Freund wrote:
> This yields plenty weird behaviour in < v10. E.g. the following is
> disallowed:
> SELECT * FROM int4mul(generate_series(1,3), 1);
> ERROR: 0A000: set-valued function called in context that cannot accept a
> set
>
Andres Freund writes:
> Cool. I wonder if we also should remove AtEOXact_CatCache()'s
> cross-checks - the resowner replacement has been in place for a while,
> and seems robust enough. They're now the biggest user of time.
Hm, biggest user of time in what workload? I've
On Thu, Apr 21, 2016 at 10:53 AM, Robert Haas wrote:
> On Thu, Apr 21, 2016 at 8:44 AM, Michael Paquier
> wrote:
>> On Thu, Apr 21, 2016 at 5:22 PM, Etsuro Fujita
>> wrote:
>>> Attached is an updated version of the
On 2017-04-13 12:56:14 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Cool. I wonder if we also should remove AtEOXact_CatCache()'s
> > cross-checks - the resowner replacement has been in place for a while,
> > and seems robust enough. They're now the biggest user of
On 2017-04-13 12:53:27 -0400, Robert Haas wrote:
> On Wed, Apr 12, 2017 at 6:58 PM, Andres Freund wrote:
> > This yields plenty weird behaviour in < v10. E.g. the following is
> > disallowed:
> > SELECT * FROM int4mul(generate_series(1,3), 1);
> > ERROR: 0A000: set-valued
1 - 100 of 112 matches
Mail list logo