On Mon, May 20, 2019 at 02:32:39PM +0300, Matwey V. Kornilov wrote:
> This patch series is to add support for spgist quadtree @<(point,circle)
> operator. The first two patches are to refactor existing code before
> implemention the new feature. The third commit is the actual implementation
>
On Tue, May 21, 2019 at 02:37:10PM +1200, David Rowley wrote:
> Maybe you could take a look at that and maybe sign up to review it?
Yes, that would be great. New VS environments are a pain to set up so
any input is welcome.
- # visual 2017 hasn't changed the nmake version to 15, so still
On Mon, May 20, 2019 at 10:22 PM Michael Paquier wrote:
> If you could clean up the CF entry, and keep only the open item in the
> list, that would be nice. Thanks.
I withdrew the CF entry; hopefully that is all that needs to be done,
but if I should do anything else let me know.
Thanks,
Paul
On Mon, May 20, 2019 at 10:18 PM Michael Paquier wrote:
> Could you define what is an "inheritance-partitioned" table? I know
> of partitioned tables, inherited tables and tables which make use
> of inheritance for partitioning (hence Inheritance Partitioning), but
> the paragraph you are adding
On Mon, May 20, 2019 at 09:55:59AM -0400, Robert Haas wrote:
> Well, it's confusing that we're not consistent about which spellings
> are accepted. The GUC system accepts true/false, on/off, and 0/1, so
> it seems reasonable to me to standardize on that treatment across the
> board. That's not
On Tue, May 21, 2019 at 01:55:46PM +0900, Amit Langote wrote:
> You could link the CF entry from the wiki (the open item), but then it
> will have to be closed when the open entry will be closed, so double work
> for whoever does the cleaning up duties. Maybe, it's better to withdraw
> it now.
On Mon, May 20, 2019 at 09:42:52PM -0700, Paul A Jungwirth wrote:
> I noticed the docs at
> https://www.postgresql.org/docs/devel/ddl-partitioning.html still say
> you can't create a foreign key referencing a partitioned table, even
> though the docs for
>
On Mon, May 20, 2019 at 9:59 PM Amit Langote
wrote:
> Would you like me to edit the wiki to add this to open items?
That would be helpful for sure. Thanks!
Paul
On 2019/05/21 14:05, Paul A Jungwirth wrote:
> On Mon, May 20, 2019 at 9:59 PM Amit Langote
> wrote:
>> Would you like me to edit the wiki to add this to open items?
>
> That would be helpful for sure. Thanks!
OK, done.
Thanks,
Amit
On 2019/05/21 13:42, Paul A Jungwirth wrote:
> I noticed the docs at
> https://www.postgresql.org/docs/devel/ddl-partitioning.html still say
> you can't create a foreign key referencing a partitioned table, even
> though the docs for
> https://www.postgresql.org/docs/devel/sql-createtable.html
On 2019/05/21 13:47, Paul A Jungwirth wrote:
> On Mon, May 20, 2019 at 9:44 PM Amit Langote
> wrote:
>> This sounds more like an open item to me [1], not something that have to
>> be postponed until the next CF.
>>
>> [1] https://wiki.postgresql.org/wiki/PostgreSQL_12_Open_Items
>
> Oh sorry, I
On Mon, May 20, 2019 at 9:44 PM Amit Langote
wrote:
> This sounds more like an open item to me [1], not something that have to
> be postponed until the next CF.
>
> [1] https://wiki.postgresql.org/wiki/PostgreSQL_12_Open_Items
Oh sorry, I already created the CF entry. Should I withdraw it? I'll
On 2019/05/21 13:39, Paul A Jungwirth wrote:
> On Mon, May 20, 2019 at 9:36 PM Amit Langote
> wrote:
>> Thanks for the patch. To avoid it getting lost in the discussions of this
>> thread, it might be better to post the patch to a separate thread.
>
> Okay, I'll make a new thread and a new CF
Hello,
I posted this to the "clean up docs for v12" thread and it was
suggested I make a new thread instead, so here it is. Sorry for the
extra noise! :-)
I noticed the docs at
https://www.postgresql.org/docs/devel/ddl-partitioning.html still say
you can't create a foreign key referencing a
On Mon, May 20, 2019 at 9:36 PM Amit Langote
wrote:
> Thanks for the patch. To avoid it getting lost in the discussions of this
> thread, it might be better to post the patch to a separate thread.
Okay, I'll make a new thread and a new CF entry. Thanks!
Hi Paul,
On 2019/05/21 13:25, Paul A Jungwirth wrote:
> I'm sorry if this is the wrong place for this or it's already been
> covered (I did scan though this whole thread and a couple others), but
> I noticed the docs at
> https://www.postgresql.org/docs/devel/ddl-partitioning.html still say
> you
Hello,
I'm sorry if this is the wrong place for this or it's already been
covered (I did scan though this whole thread and a couple others), but
I noticed the docs at
https://www.postgresql.org/docs/devel/ddl-partitioning.html still say
you can't create a foreign key referencing a partitioned
On Tue, May 21, 2019 at 12:33:54PM +1200, David Rowley wrote:
> I guess it's not impossible for pg_dump to fail on this even without
> this change. If someone had increased the limit on an instance with
> say 16k page to something over what TOAST_TUPLE_TARGET_MAIN would be
> on a standard
Hi,
On 2019/05/21 7:59, Andres Freund wrote:
> On 2019-05-20 13:20:01 -0500, Justin Pryzby wrote:
>> @@ -3052,7 +3052,7 @@ SCRAM-SHA-256$iteration
>> count:
>> simplifies ATTACH/DETACH PARTITION operations:
>> the partition dependencies need only be added or removed.
>>
Thomas Munro writes:
> On Mon, May 20, 2019 at 4:46 PM Tom Lane wrote:
>> Note that in the discussion that led up to 624e440a, we never did
>> think that we'd completely explained the original irreproducible
>> failure.
>>
>> I think I've seen a couple of other cases of this same failure
>> in
On 2019/05/21 11:29, Alvaro Herrera wrote:
> On 2019-May-20, Amit Langote wrote:
>
>> Should we add this to open items?
>
> Yeah. I'm AFK this week, but can handle it afterwards. The fix already
> missed beta1, so I don't think there's a problem with taking a little
> bit longer.
OK, added.
On Tue, May 21, 2019 at 2:10 AM Fujii Masao wrote:
>
> On Fri, May 17, 2019 at 10:21 AM Kyotaro HORIGUCHI
> wrote:
> >
> > We now have several syntax elements seemingly the same but behave
> > different way.
> >
> > At Thu, 16 May 2019 15:29:36 -0400, Robert Haas
> > wrote in
> >
> > > On
On Tue, 21 May 2019 at 05:46, Juan José Santamaría Flecha
wrote:
> While trying to setup a test environment under Windows I have managed to
> build the source using the latest Visual Studio 2019 [1].
>
> It's only been tested in this one environment, Windows 10 x64, but the
> changes seem tool
On 2019-May-20, Amit Langote wrote:
> Should we add this to open items?
Yeah. I'm AFK this week, but can handle it afterwards. The fix already
missed beta1, so I don't think there's a problem with taking a little
bit longer.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
Hi Andrew,
On 2019-03-30 16:42:16 -0400, Andrew Dunstan wrote:
> On some machines (*cough* Mingw *cough*) installs are very slow. We've
> ameliorated this by allowing temp installs to be reused, but the
> pg_upgrade Makefile never got the message. Here's a patch that does
> that. I'd like to
On Mon, May 20, 2019 at 3:17 PM Andres Freund wrote:
>
>
>
> Improve speed of btree index insertions (Peter Geoghegan,
> Alexander Korotkov)
>
My concern here (which I believe Alexander shares) is that it doesn't
make sense to group these two items together.
Andres Freund writes:
> On 2019-05-20 18:56:50 -0400, Tom Lane wrote:
>> I'm not sure which of my commits you want me to opine on, other than
> That was one of the main ones. I'm also specifically wondering about:
>> Author: Tom Lane
>> 2019-02-09 [1fb57af92] Create the infrastructure for
On Tue, 14 May 2019 at 18:49, Michael Paquier wrote:
> Now, can we really increase the minimum value as you and Pavan
> propose? For now anything between 128 and TOAST_TUPLE_TARGET gets
> silently ignored, but if we increase the threshold as you propose we
> could prevent some dumps to be
Thomas Munro writes:
> On Mon, May 20, 2019 at 4:46 PM Tom Lane wrote:
>> Note that in the discussion that led up to 624e440a, we never did
>> think that we'd completely explained the original irreproducible
>> failure.
> I think it might be dependent on incidental vacuum/analyze activity
>
On Tue, 21 May 2019 at 10:17, Andres Freund wrote:
> commit 4da597edf1bae0cf0453b5ed6fc4347b6334dfe1
> Author: Andres Freund
> Date: 2018-11-16 16:35:11 -0800
>
> Make TupleTableSlots extensible, finish split of existing slot type.
>
>Given that those commits entail an API break
On Mon, May 20, 2019 at 4:46 PM Tom Lane wrote:
> Thomas Munro writes:
> > Here's a one-off regression test failure of a sort that commit
> > 624e440a intended to fix.
>
> Note that in the discussion that led up to 624e440a, we never did
> think that we'd completely explained the original
Hi,
On 2019-05-21 00:08:25 +0100, Andrew Gierth wrote:
> > "Andres" == Andres Freund writes:
>
> Andres> Any chance for you to propose a text?
>
> This is what I posted before; I'm not 100% happy with it but it's still
> better than any of the other versions:
> * Output REAL and DOUBLE
On 2019-05-20 18:56:50 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Note that I've added a few questions to individuals involved with
> > specific points. If you're in the To: list, please search for your name.
>
> I'm not sure which of my commits you want me to opine on, other than
That
> "Andres" == Andres Freund writes:
Andres> Any chance for you to propose a text?
This is what I posted before; I'm not 100% happy with it but it's still
better than any of the other versions:
* Output REAL and DOUBLE PRECISION values in shortest-exact format by
default, and change
Hi,
On 2019-05-20 13:20:01 -0500, Justin Pryzby wrote:
> On Sat, Mar 30, 2019 at 05:43:33PM -0500, Justin Pryzby wrote:
> Thanks in advance for any review.
I find these pretty tedious to work with. I'm somewhat dyslexic, not a
native speaker. So it requires a lot of concentration to go through
Hi,
On 2019-05-20 23:56:33 +0100, Andrew Gierth wrote:
> [ To: header pruned ]
>
> > "Andres" == Andres Freund writes:
>
> Andres>
> Andres> Avoid performing unnecessary rounding of Andres> linkend="datatype-float">REAL and
> DOUBLE
> Andres> PRECISION values
Andres Freund writes:
> Note that I've added a few questions to individuals involved with
> specific points. If you're in the To: list, please search for your name.
I'm not sure which of my commits you want me to opine on, other than
>
>
>
>Allow RECORD and RECORD[] to be
[ To: header pruned ]
> "Andres" == Andres Freund writes:
Andres>
Andres> Avoid performing unnecessary rounding oflinkend="datatype-float">REAL and
DOUBLE
Andres> PRECISION values (Andrew Gierth)
Andres>
Andres>
Andres> This dramatically
Hi,
Note that I've added a few questions to individuals involved with
specific points. If you're in the To: list, please search for your name.
On 2019-05-11 16:33:24 -0400, Bruce Momjian wrote:
> I have posted a draft copy of the PG 12 release notes here:
>
>
On Mon, May 20, 2019 at 12:15:49PM -0700, Mark Wong wrote:
> On Sun, May 19, 2019 at 02:38:26PM -0700, Andres Freund wrote:
> > Hi,
> >
> > On 2019-05-14 08:31:37 -0700, Mark Wong wrote:
> > > Ok, I have this added to everyone now.
> > >
> > > I think I also have caught up on this thread, but
On Mon, May 20, 2019 at 01:13:50PM -0500, Jeremy Finzel wrote:
> I have a question about this (really exciting) feature coming in pg12:
>
> Allow ALTER TABLE .. SET DATA TYPE timestamp/timestamptz to avoid a table
> rewrite when the session time zone is UTC (Noah Misch)
>
> In the UTC time zone,
> On Mon, May 20, 2019 at 9:20 PM Andres Freund wrote:
>
> Hi,
>
> On May 20, 2019 12:14:30 PM PDT, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> >> On Thu, May 16, 2019 at 8:56 PM Fujii Masao
> >wrote:
> >>
> >> Yes. Thanks for the comment!
> >> Attached is the updated version of the patch.
>
Hi,
On May 20, 2019 12:14:30 PM PDT, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>> On Thu, May 16, 2019 at 8:56 PM Fujii Masao
>wrote:
>>
>> Yes. Thanks for the comment!
>> Attached is the updated version of the patch.
>> It adds such common rule.
>
>If I understand correctly, it resulted in
On Sun, May 19, 2019 at 02:38:26PM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-05-14 08:31:37 -0700, Mark Wong wrote:
> > Ok, I have this added to everyone now.
> >
> > I think I also have caught up on this thread, but let me know if I
> > missed anything.
>
> I notice
>
> On Thu, May 16, 2019 at 8:56 PM Fujii Masao wrote:
>
> Yes. Thanks for the comment!
> Attached is the updated version of the patch.
> It adds such common rule.
If I understand correctly, it resulted in the commit fc7c281f8. For some reason
it breaks vacuum tests for me, is it expected?
On Sun, May 19, 2019 at 4:07 PM Thomas Munro wrote:
> On Sat, May 18, 2019 at 12:15 PM Melanie Plageman
> wrote:
> > On Thu, May 16, 2019 at 3:22 PM Thomas Munro
> wrote:
> >> Admittedly I don't have a patch, just a bunch of handwaving. One
> >> reason I haven't attempted to write it is
On Sat, Mar 30, 2019 at 05:43:33PM -0500, Justin Pryzby wrote:
> I reviewed docs like this:
> git log -p remotes/origin/REL_11_STABLE..HEAD -- doc
On Fri, Apr 19, 2019 at 05:00:26PM +0900, Michael Paquier wrote:
> However most of what you are proposing does not seem necessary, and the
> current
On Mon, May 20, 2019 at 04:09:24PM +0100, Dean Rasheed wrote:
On Mon, 20 May 2019 at 14:32, Tom Lane wrote:
Dean Rasheed writes:
> On Sun, 19 May 2019 at 23:45, Tomas Vondra
wrote:
>> Oh, right. It still has the disadvantage that it obfuscates the actual
>> data stored in the
I have a question about this (really exciting) feature coming in pg12:
Allow ALTER TABLE .. SET DATA TYPE timestamp/timestamptz to avoid a table
rewrite when the session time zone is UTC (Noah Misch)
In the UTC time zone, the data types are binary compatible.
We actually want to migrate all of
Hello,
While trying to setup a test environment under Windows I have managed to
build the source using the latest Visual Studio 2019 [1].
It's only been tested in this one environment, Windows 10 x64, but the
changes seem tool dependant only.
Regards,
Juan José Santamaría Flecha
[1]
On Fri, May 17, 2019 at 10:21 AM Kyotaro HORIGUCHI
wrote:
>
> We now have several syntax elements seemingly the same but behave
> different way.
>
> At Thu, 16 May 2019 15:29:36 -0400, Robert Haas wrote
> in
> > On Thu, May 16, 2019 at 2:56 PM Fujii Masao wrote:
> > > Yes. Thanks for the
+1 on this one...
MySQL and derivatives support it very well.. it is a standard that can be
used with either haproxy or better, ProxySQL.
Would be nice to have it in core.
It is a show stopper for us to use proxying because of compliance and
tracability reasons.
Le dim. 19 mai 2019 11:36
On Mon, May 20, 2019 at 11:04 PM Antonin Houska wrote:
>
> Someone probably forgot to update the comment when changing the arguments.
Thanks for the patch! Committed.
Regards,
--
Fujii Masao
On 19.05.2019 18:36, Julien Riou wrote:
Hello,
Nowadays, PostgreSQL is often used behind proxies. Some are PostgreSQL
protocol aware (Pgpool, PgBouncer), some are pure TCP (HAProxy). From
the database instance point of view, all clients come from the proxy.
There are two major problems with
Hi,
On May 20, 2019 6:23:46 AM PDT, Robert Haas wrote:
>On Sun, May 19, 2019 at 2:36 PM Andres Freund
>wrote:
>> Not sure I understand the distinction you're trying to make with the
>> variable renaming. The combine function is also a transition
>function,
>> no?
>
>Not in my mental model.
On Mon, 20 May 2019 at 14:32, Tom Lane wrote:
>
> Dean Rasheed writes:
> > On Sun, 19 May 2019 at 23:45, Tomas Vondra
> > wrote:
> >> Oh, right. It still has the disadvantage that it obfuscates the actual
> >> data stored in the pg_stats_ext_data (or whatever would it be called),
> >> so e.g.
On Mon, May 20, 2019 at 09:32:24AM -0400, Tom Lane wrote:
Dean Rasheed writes:
On Sun, 19 May 2019 at 23:45, Tomas Vondra wrote:
Oh, right. It still has the disadvantage that it obfuscates the actual
data stored in the pg_stats_ext_data (or whatever would it be called),
so e.g. functions
On Mon, May 20, 2019 at 01:25:52PM +1200, Thomas Munro wrote:
On Mon, May 20, 2019 at 12:22 PM Tomas Vondra
wrote:
On Mon, May 20, 2019 at 11:07:03AM +1200, Thomas Munro wrote:
>First let me restate the PostgreSQL terminology for this stuff so I
>don't get confused while talking about it:
>
>*
On Fri, May 17, 2019 at 5:12 PM Ashwin Agrawal wrote:
>> I'd rather see this have a relation_ prefix.
>
> +1 to overall patch with that comment incorporated. This seems simple enough
> to incorporate for v12. Though stating that blind-folded with what else is
> remaining to be must done for
Someone probably forgot to update the comment when changing the arguments.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index c00b63c751..527522f165 100644
--- a/src/backend/access/transam/xlog.c
On Thu, May 16, 2019 at 9:21 PM Kyotaro HORIGUCHI
wrote:
> I think we don't need to support 1/0 as boolean here (it's
> unnatural) and the documentation of VACUUM/ANALYZE should be
> fixed.
Well, it's confusing that we're not consistent about which spellings
are accepted. The GUC system accepts
Akim Demaille writes:
> It is for the same reasons that I would recommend not using associativity
> directives (%left, %right, %nonassoc) where associativity plays no role:
> %precedence is made for this. But it was introduced in Bison 2.7.1
> (2013-04-15), and I don't know if requiring it is
On Fri, May 17, 2019 at 4:55 PM Andres Freund wrote:
> Robert, this indeed looks near trivial. What do you think?
Hmm, yeah, I guess that'd be OK.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Greetings,
* Raghav Jajodia (jajodia.rag...@gmail.com) wrote:
> I am Raghav Jajodia, a software engineer from Bangalore, India. I have been
> a diligent open source contributor and have been a student under the
> following:
> 1. Google Summer of Code 2017 student
> 2. OWASP Code Sprint Winner
>
Greetings,
* DHRUVI VADALIA (dhruvi.vada...@somaiya.edu) wrote:
> I'm a 3rd year Computer Engineer and I'm applying for GSoD.
[...]
> My *experience* in *technical writing* includes *project reports for
> college projects* and technical documentation such as *SRS*, etc. It was
> also one of my
Greetings,
* Manish Devgan (manish.ns...@gmail.com) wrote:
> This is in context with the previous mail I created dated April 30, 2019 in
> regard to GSoD'19.
I might be missing it, but I don't see a prior email from you, and our
archives only show this email when I search across all lists.
> I
Greetings,
* Sascha Kuhl (yogidaba...@gmail.com) wrote:
> Can I obtain a document with the organisational structure of this mailing
> list. I would like to foresee what happens with my email.
There is no formal document and we don't have any control over what
happens down-stream of us (there are
Hi Tom,
> Le 19 mai 2019 à 20:27, Tom Lane a écrit :
>
> Akim Demaille writes:
>> In the following two proposed patches, I remove directives that are
>> completely useless.
>
> I'm far from convinced that the proposed changes in gram.y are a good
> idea. Both [] and . (field selection) *are*
Hi,
Can I obtain a document with the organisational structure of this mailing
list. I would like to foresee what happens with my email.
Concretely I would like to know if there is a filtering and/or relaying
person or algorithm involved
Thanks
Sascha
Dean Rasheed writes:
> On Sun, 19 May 2019 at 23:45, Tomas Vondra
> wrote:
>> Oh, right. It still has the disadvantage that it obfuscates the actual
>> data stored in the pg_stats_ext_data (or whatever would it be called),
>> so e.g. functions would have to do additional checks to make sure it
On Sun, May 19, 2019 at 2:36 PM Andres Freund wrote:
> Not sure I understand the distinction you're trying to make with the
> variable renaming. The combine function is also a transition function,
> no?
Not in my mental model. It's true that a combine function is used in
a similar manner to a
On Tue, May 14, 2019 at 2:19 AM Andres Freund wrote:
> How would this protect against the issues I mentioned where recovery
> starts from an earlier checkpoint and the basebackup could pick up a
> random set of version of the different forks?
>
> I don't like the idea of expanding the use of
On Mon, 20 May 2019 at 19:59, Kyotaro HORIGUCHI
wrote:
> -numArguments = get_aggregate_argtypes(aggref, inputTypes);
> +numTransFnArgs = get_aggregate_argtypes(aggref, transFnInputTypes);
>
> If the function retrieves argument types of transform functions,
> it would be better
Hi,
This patch series is to add support for spgist quadtree @<(point,circle)
operator. The first two patches are to refactor existing code before
implemention the new feature. The third commit is the actual implementation
provided with a set of simple unit tests.
Changes since v2:
- fix coding
Hello.
I couldn't understand the multiple argument lists with confident
so the patch was born from a guess^^; Sorry for the confusing but
I'm relieved by knowing that it was not so easy to understand.
At Mon, 20 May 2019 17:27:10 +1200, David Rowley
wrote in
> On Mon, 20 May 2019 at 13:20,
On Sun, 19 May 2019 at 23:45, Tomas Vondra wrote:
>
> Oh, right. It still has the disadvantage that it obfuscates the actual
> data stored in the pg_stats_ext_data (or whatever would it be called),
> so e.g. functions would have to do additional checks to make sure it
> actually is the right
On 2019-05-14 04:56, Bruce Momjian wrote:
> On Mon, May 13, 2019 at 04:34:34PM -0400, Tom Lane wrote:
>> Magnus Hagander writes:
>>> On Mon, May 13, 2019 at 10:00 PM Robert Haas wrote:
On Mon, May 13, 2019 at 3:54 PM Peter Eisentraut
wrote:
> I'm not sure doc/bug.template still
Hello.
At Thu, 16 May 2019 23:50:50 -0700, Noah Misch wrote in
<20190517065050.ga1298...@rfd.leadboat.com>
> On Tue, May 14, 2019 at 01:59:10PM +0900, Kyotaro HORIGUCHI wrote:
> > At Sun, 12 May 2019 17:37:05 -0700, Noah Misch wrote in
> > <20190513003705.ga1202...@rfd.leadboat.com>
> > > On
po 20. 5. 2019 v 7:56 odesílatel Corey Huinker
napsal:
>
>> You can pass table name as text or table object id as regclass type.
>>
>> inside procedure you should to use dynamic sql - execute statement.
>> Generally you cannot to use a variable as table or column name ever.
>>
>> Dynamic SQL is
79 matches
Mail list logo
