On 13 November 2017 at 12:55, Alvaro Herrera wrote:
> Somehow I managed to include an unrelated patch as attachment. Here's
> another attempt (on which I also lightly touched ddl.sgml with relevant
> changes).
Looks good. Some minor comments below.
0001- Simplify
Seems useful as separate step;
On Mon, Oct 30, 2017 at 9:49 AM, Nikolay Shaplov wrote:
> В письме от 3 сентября 2017 11:45:43 пользователь Alvaro Herrera написал:
>
> Yet another git rebase. This patch can be applied to master branch again.
>
> For this patch no review needed now, as I will offer part of it (one that
> refuses
Thank you for pointing out and comments.
On Fri, Nov 10, 2017 at 12:38 AM, Tom Lane wrote:
> Robert Haas writes:
>> No, that's not right. Now that you mention it, I realize that tuple
>> locks can definitely cause deadlocks. Example:
>
> Yeah. Foreign-key-related tuple locks are another rich
On 14 November 2017 at 01:55, David Rowley wrote:
> I'll try to continue with the review tomorrow, but I think some other
> reviews are also looming too.
I started looking at this again today. Here's the remainder of my review.
29. ExecSetupChildParentMap gets called here for non-partitioned rel
PFA the updated patches.
On Tue, Nov 14, 2017 at 11:45 AM, Beena Emerson wrote:
> Hello Amul,
>
> Thank you for reviewing.
>
> On Fri, Nov 10, 2017 at 4:33 PM, amul sul wrote:
>> On Thu, Nov 9, 2017 at 4:48 PM, Beena Emerson
>> wrote:
>>> Hello all,
>>>
>>> Here is the updated patch which is r
Hello Amul,
Thank you for reviewing.
On Fri, Nov 10, 2017 at 4:33 PM, amul sul wrote:
> On Thu, Nov 9, 2017 at 4:48 PM, Beena Emerson wrote:
>> Hello all,
>>
>> Here is the updated patch which is rebased over v10 of Amit Langote's
>> path towards faster pruning patch [1]. It modifies the PartSc
On Tue, Nov 14, 2017 at 6:49 PM, Kohei KaiGai wrote:
> 2017-11-14 10:33 GMT+09:00 Thomas Munro :
>> On Tue, Nov 14, 2017 at 1:11 PM, Kohei KaiGai wrote:
>>> Any opinions?
>>
>> The only reason I can think of for having it in core is that you might
>> want to use standard SQL notation FLOAT(10) to
2017-11-14 10:33 GMT+09:00 Thomas Munro :
> On Tue, Nov 14, 2017 at 1:11 PM, Kohei KaiGai wrote:
>> Any opinions?
>
> The only reason I can think of for having it in core is that you might
> want to use standard SQL notation FLOAT(10) to refer to it. Right now
> our parser converts that to float4
2017-11-14 10:32 GMT+09:00 Andres Freund :
> On 2017-11-13 20:21:47 -0500, Tom Lane wrote:
>> Kohei KaiGai writes:
>> > How about your thought for support of half-precision floating point,
>> > FP16 in short?
>>
>> This sounds like a whole lotta work for little if any gain. There's not
>> going t
2017-11-14 10:21 GMT+09:00 Tom Lane :
> Kohei KaiGai writes:
>> How about your thought for support of half-precision floating point,
>> FP16 in short?
>
> This sounds like a whole lotta work for little if any gain. There's not
> going to be any useful performance gain from using half-width floats
On Tue, Nov 14, 2017 at 10:30 AM, Robert Haas wrote:
> On Sat, Nov 11, 2017 at 10:48 PM, Thomas Munro
> wrote:
>> How about parallel_leader_participation = on|off? The attached
>> version has it that way, and adds regression tests to exercise on, off
>> and off-but-couldn't-start-any-workers for
As suggested from Joe i changed the db definition as enclosed.
Now when i do:
select * fom schools
all works fine
but when i do:
select * from rls_test
select * from _rls_test_security_barrier
select * from public._rls_test_with_check_local
select * from _rls_test_with_check_local_cascade
a
On Tue, Nov 14, 2017 at 2:39 AM, Robert Haas wrote:
> On Sat, Nov 11, 2017 at 7:19 AM, Amit Kapila wrote:
>> I have tried to follow the practice we have used for param extern
>> params (SerializeParamList is in params.c) and most of the handling of
>> initplans is done in nodeSubplan.c, so I choo
On Mon, Nov 13, 2017 at 6:56 PM, Masahiko Sawada wrote:
>/*
> * We would like to prevent concurrent cleanup process. For that we will
> * lock metapage in exclusive mode using LockPage() call. Nobody other
> * will use that lock for metapage, so we keep possibility of concurrent
>
On 2017-11-13 19:03:41 -0800, Andres Freund wrote:
> Hi,
>
> On 2017-11-03 07:53:30 -0700, Andres Freund wrote:
> > Here's that patch. I've stared at this some, and Robert did too. Robert
> > mentioned that the commit message might need some polish and I'm not
> > 100% sure about the error messag
On 13 November 2017 at 22:46, Amit Langote
wrote:
> On 2017/11/10 12:30, Kyotaro HORIGUCHI wrote:
>> In 0002, bms_add_range has a bit naive-looking loop
>>
>> + while (wordnum <= uwordnum)
>> + {
>> + bitmapword mask = (bitmapword) ~0;
>> +
>> + /* If working on the
On Mon, Nov 13, 2017 at 2:09 AM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> Hi!
>
> On Mon, Nov 13, 2017 at 6:47 AM, Connor Wolf <
> conn...@imaginaryindustries.com> wrote:
>
>> Ok, I've managed to get my custom index working.
>>
>
> Good!
>
> It's all on github here: https://github.
Hi,
On 2017-11-03 07:53:30 -0700, Andres Freund wrote:
> Here's that patch. I've stared at this some, and Robert did too. Robert
> mentioned that the commit message might need some polish and I'm not
> 100% sure about the error message texts yet.
>
> I'm not yet convinced that the new elog in va
On Tue, Nov 14, 2017 at 10:48 AM, Peter Geoghegan wrote:
> On Mon, Nov 13, 2017 at 5:07 PM, Masahiko Sawada
> wrote:
>>> I've been suspicious of that commit (and related commits) for a while
>>> now [1]. I think that it explains a couple of different problem
>>> reports that we have seen.
>>
>>
On Tue, Nov 14, 2017 at 10:52 AM, Eric Lam wrote:
> Please unsubscribe me.
(Please do not hijack the threads)
Help yourself:
https://www.postgresql.org/community/lists/subscribe/
--
Michael
Hi,
Please unsubscribe me.
thanksEric
On Tuesday, November 14, 2017, 2:02:04 AM GMT+8, Peter Geoghegan
wrote:
On Mon, Nov 13, 2017 at 12:25 AM, Masahiko Sawada
wrote:
> Commit e2c79e14 prevented multiple cleanup process for pending list in
> GIN index. But I think that there is still
On Tue, Nov 14, 2017 at 3:08 AM, Robert Haas wrote:
> On Sun, Nov 12, 2017 at 2:29 AM, Amit Kapila wrote:
>> Agreed. Your change looks good to me.
>
> OK, committed.
>
Thank you.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Mon, Nov 13, 2017 at 5:07 PM, Masahiko Sawada wrote:
>> I've been suspicious of that commit (and related commits) for a while
>> now [1]. I think that it explains a couple of different problem
>> reports that we have seen.
>
> Yeah, the problem here is that vacuum and analyze don't acquire a
>
On Tue, Nov 14, 2017 at 1:11 PM, Kohei KaiGai wrote:
> Any opinions?
The only reason I can think of for having it in core is that you might
want to use standard SQL notation FLOAT(10) to refer to it. Right now
our parser converts that to float4 but it could map precisions up to
10 to float2. Th
On 2017-11-13 20:21:47 -0500, Tom Lane wrote:
> Kohei KaiGai writes:
> > How about your thought for support of half-precision floating point,
> > FP16 in short?
>
> This sounds like a whole lotta work for little if any gain. There's not
> going to be any useful performance gain from using half-w
Kohei KaiGai writes:
> How about your thought for support of half-precision floating point,
> FP16 in short?
This sounds like a whole lotta work for little if any gain. There's not
going to be any useful performance gain from using half-width floats
except in an environment where it's the indivi
On Tue, Nov 14, 2017 at 3:01 AM, Peter Geoghegan wrote:
> On Mon, Nov 13, 2017 at 12:25 AM, Masahiko Sawada
> wrote:
>> Commit e2c79e14 prevented multiple cleanup process for pending list in
>> GIN index. But I think that there is still possibility that vacuum
>> could miss tuples to be deleted
On Tue, Nov 14, 2017 at 6:50 AM, Tom Lane wrote:
> Fabien COELHO writes:
Note that if "c" is freed by "d" (drop), then it may be worth considering
that "t" (table) could be replaced by "c" (create).
>
>>> I thought about that, but the argument that 'c' might mean different
>>> sorts of
On 14 November 2017 at 07:39, Alvaro Herrera wrote:
> David Rowley wrote:
>> A patch to fix this is attached.
>
> Thanks, pushed.
Thanks for pushing.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Tue, Nov 14, 2017 at 3:59 AM, Robert Haas wrote:
> On Mon, Nov 13, 2017 at 3:24 AM, amul sul wrote:
>> Updated patch attached -- Adjusted code comment to survive against pgindent.
>
> That's not the right fix, or at least it's not complete. You
> shouldn't call PG_GETARG_...(n) until you've v
On Tue, Nov 14, 2017 at 8:38 AM, Bossart, Nathan wrote:
> Fair points. If we added an option to pg_resetwal, should we bother
> trying to handle the WAL filename overlap that Jeremy mentioned? The
> -l option gives us the ability to set the WAL starting address
> manually, but it might not be te
Hello,
How about your thought for support of half-precision floating point,
FP16 in short?
https://en.wikipedia.org/wiki/Half-precision_floating-point_format
Probably, it does not make sense for most of our known workloads. Our supported
hardware platform does not support FP16 operations, thus,
On 11/13/17, 5:09 PM, "Tom Lane" wrote:
> Michael Paquier writes:
>> On Tue, Nov 14, 2017 at 7:32 AM, Andres Freund wrote:
>>> Even if that's the case, I fail to see why it'd be a good idea to have
>>> any sort of pg_upgrade integration here. We should make pg_resetwal's
>>> checks for this goo
Michael Paquier writes:
> On Tue, Nov 14, 2017 at 7:32 AM, Andres Freund wrote:
>> Even if that's the case, I fail to see why it'd be a good idea to have
>> any sort of pg_upgrade integration here. We should make pg_resetwal's
>> checks for this good enough, and not conflate something unrelated
On Tue, Nov 14, 2017 at 7:32 AM, Andres Freund wrote:
> On 2017-11-14 07:26:22 +0900, Michael Paquier wrote:
>> On Tue, Nov 14, 2017 at 6:11 AM, Andres Freund wrote:
>> > Hm. I'm not really on-board with doing this in pg_upgrade. A more
>> > logical place seems to be pg_resetwal or something - th
On Mon, Nov 13, 2017 at 10:37 PM, Stephen Frost wrote:
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> auth-scram.c is visibly not able to do things in a deterministic way,
>> that's more determinisitc:
>
> Hah, excellent point, will push in a moment (also to test that the
> -committers
On 2017-11-14 07:26:22 +0900, Michael Paquier wrote:
> On Tue, Nov 14, 2017 at 6:11 AM, Andres Freund wrote:
> > Hm. I'm not really on-board with doing this in pg_upgrade. A more
> > logical place seems to be pg_resetwal or something - there's no need to
> > force a pg_upgrade cycle (which is pret
On Tue, Nov 14, 2017 at 6:11 AM, Andres Freund wrote:
> Hm. I'm not really on-board with doing this in pg_upgrade. A more
> logical place seems to be pg_resetwal or something - there's no need to
> force a pg_upgrade cycle (which is pretty expensive on clusters with a
> significant number of objec
Geoff Winkless writes:
> The removal of the [HACKERS] (etc) header will be frustrating for me: I do
> not sort mailing lists into folders (I simply scan the "Forums" autofilter
> in gmail) and have no wish to do so, and there is no way to make such a
> machine-readable header visible in gmail.
I'
Oliver Ford writes:
> On Monday, 13 November 2017, Tom Lane wrote:
>> I don't follow your concern? If "$" is not the correct currency
>> symbol for the locale, we shouldn't accept it as a match to an L format.
>> Your patch is tightening what we will accept as a match to a G format,
>> so I don'
Fabien COELHO writes:
>>> Note that if "c" is freed by "d" (drop), then it may be worth considering
>>> that "t" (table) could be replaced by "c" (create).
>> I thought about that, but the argument that 'c' might mean different
>> sorts of create steps (e.g. create index) seemed reasonable. I th
On Tue, Sep 26, 2017 at 3:45 PM, Masahiko Sawada wrote:
> On Tue, Sep 26, 2017 at 10:36 AM, Vaishnavi Prabakaran
> wrote:
>> On Wed, Sep 13, 2017 at 9:59 AM, Daniel Gustafsson wrote:
>>> I’m not entirely sure why this was flagged as "Waiting for Author” by the
>>> automatic run, the patch applie
On Sun, Nov 12, 2017 at 2:29 AM, Amit Kapila wrote:
> Agreed. Your change looks good to me.
OK, committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Sat, Nov 11, 2017 at 10:48 PM, Thomas Munro
wrote:
> How about parallel_leader_participation = on|off? The attached
> version has it that way, and adds regression tests to exercise on, off
> and off-but-couldn't-start-any-workers for both kinds of gather node.
This looks mostly fine to me, bu
Hi,
On 2017-11-10 15:46:11 +, Bossart, Nathan wrote:
> The thread for the recent change to allow setting the WAL segment size at
> initdb time [0] included a bit of discussion regarding pg_upgrade [1],
> where it was suggested that relaxing an error check (presumably in
> check_control_data())
On Sat, Nov 11, 2017 at 7:19 AM, Amit Kapila wrote:
> I have tried to follow the practice we have used for param extern
> params (SerializeParamList is in params.c) and most of the handling of
> initplans is done in nodeSubplan.c, so I choose to keep the newly
> added functions there. However, I
On Monday, 13 November 2017, Tom Lane wrote:
> Oliver Ford > writes:
> > On Sun, Nov 12, 2017 at 7:00 PM, Tom Lane > wrote:
> >> * Don't we need to fix the NUM_L (currency symbol) case in the
> >> same manner? (The NUM_D and NUM_S cases are handled in
> >> NUM_numpart_from_char and seem ok at a
On Fri, Nov 10, 2017 at 4:04 PM, Michael Paquier
wrote:
> On Sat, Nov 11, 2017 at 12:46 AM, Bossart, Nathan wrote:
>> Allowing changes to the WAL segment size during pg_upgrade seems like a
>> nice way to avoid needing a dump and load, so I would like to propose
>> adding support for this. I'd b
On Fri, Nov 10, 2017 at 4:42 PM, Amit Khandekar wrote:
> Attached is v23 patch that has just the above changes (and also
> rebased on hash-partitioning changes, like update.sql). I am still
> doing some sanity testing on this, although regression passes.
The test coverage[1] is 96.62%. Nice work
On Mon, Nov 13, 2017 at 3:24 AM, amul sul wrote:
> Updated patch attached -- Adjusted code comment to survive against pgindent.
That's not the right fix, or at least it's not complete. You
shouldn't call PG_GETARG_...(n) until you've verified that
PG_ARGISNULL(n) returns false.
Also, I don't th
Note that if "c" is freed by "d" (drop), then it may be worth considering
that "t" (table) could be replaced by "c" (create).
I thought about that, but the argument that 'c' might mean different
sorts of create steps (e.g. create index) seemed reasonable. I think
we're best off leaving it as
2017-11-13 19:19 GMT+01:00 David Steele :
> Hi Pavel,
>
> On 11/10/17 2:33 AM, Pavel Stehule wrote:
>
>>
>> I am sending some notes, experience about usage of pgAudit.
>>
>
> Thanks for the input! I'm not sure this is the best forum for comments,
> however, since pgAudit is not part of Postgres.
David Rowley wrote:
> A patch to fix this is attached.
Thanks, pushed.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Fabien COELHO writes:
>> Masahiko Sawada writes:
>>> [ pgbench_custom_initialization_v16.patch ]
>> I'm starting to review this patch, and I wonder how it is that you
>> ended up with "c" as the command letter for dropping existing tables.
>> Seems like "d" for DROP would be much less confusing.
Hello Tom,
Masahiko Sawada writes:
[ pgbench_custom_initialization_v16.patch ]
I'm starting to review this patch, and I wonder how it is that you
ended up with "c" as the command letter for dropping existing tables.
Seems like "d" for DROP would be much less confusing. I see that at
one po
Hello Steve,
printf("number of transactions actually processed: " INT64_FORMAT
"/%d\n",
- total->cnt - total->skipped, nxacts * nclients);
+ total->cnt, nxacts * nclients);
I think you want ntx instead of total->cnt here.
Inde
Hi Pavel,
On 11/10/17 2:33 AM, Pavel Stehule wrote:
I am sending some notes, experience about usage of pgAudit.
Thanks for the input! I'm not sure this is the best forum for comments,
however, since pgAudit is not part of Postgres.
Issues can be opened at the github site:
https://github.c
On 5 August 2017 at 10:03, Fabien COELHO wrote:
>
> Hello Rod,
>
> Patch applies cleanly, make html ok, new table looks good to me.
>
> I've turned it "Ready for Committer".
>
I didn't really finish committing this in the last commitfest, before
getting distracted by a security issue, so returnin
On Mon, Nov 13, 2017 at 12:25 AM, Masahiko Sawada wrote:
> Commit e2c79e14 prevented multiple cleanup process for pending list in
> GIN index. But I think that there is still possibility that vacuum
> could miss tuples to be deleted if someone else is cleaning up the
> pending list.
I've been sus
> On 13 Nov 2017, at 17:45, Geoff Winkless wrote:
>
> On 13 November 2017 at 17:10, Alvaro Herrera wrote:
>> Geoff Winkless wrote:
>>> The removal of the [HACKERS] (etc) header will be frustrating for me: I do
>>> not sort mailing lists into folders (I simply scan the "Forums" autofilter
>>> i
On 13 November 2017 at 17:10, Alvaro Herrera wrote:
> Geoff Winkless wrote:
>> The removal of the [HACKERS] (etc) header will be frustrating for me: I do
>> not sort mailing lists into folders (I simply scan the "Forums" autofilter
>> in gmail) and have no wish to do so, and there is no way to mak
Geoff Winkless wrote:
> The removal of the [HACKERS] (etc) header will be frustrating for me: I do
> not sort mailing lists into folders (I simply scan the "Forums" autofilter
> in gmail) and have no wish to do so, and there is no way to make such a
> machine-readable header visible in gmail.
Mayb
Masahiko Sawada writes:
> [ pgbench_custom_initialization_v16.patch ]
I'm starting to review this patch, and I wonder how it is that you
ended up with "c" as the command letter for dropping existing tables.
Seems like "d" for DROP would be much less confusing. I see that at
one point "d" meant t
Greetings,
* Geoff Winkless (pgsqlad...@geoff.dj) wrote:
> The removal of the [HACKERS] (etc) header will be frustrating for me: I do
> not sort mailing lists into folders (I simply scan the "Forums" autofilter
> in gmail) and have no wish to do so, and there is no way to make such a
> machine-rea
Hi,
I also find it very useful to be able to identify the list by the subject.
The way to address this is, as Geoff mentions, to NOT include subject in
your DKIM signature.
Regards,
Ken
On Mon, Nov 13, 2017 at 04:41:59PM +, Geoff Winkless wrote:
> The removal of the [HACKERS] (etc) header wi
On Mon, Nov 13, 2017 at 4:41 PM, Geoff Winkless wrote:
> The removal of the [HACKERS] (etc) header will be frustrating for me: I do
> not sort mailing lists into folders (I simply scan the "Forums" autofilter
> in gmail) and have no wish to do so, and there is no way to make such a
> machine-read
The removal of the [HACKERS] (etc) header will be frustrating for me: I do
not sort mailing lists into folders (I simply scan the "Forums" autofilter
in gmail) and have no wish to do so, and there is no way to make such a
machine-readable header visible in gmail.
Perhaps those users who wish to us
Oliver Ford writes:
> On Sun, Nov 12, 2017 at 7:00 PM, Tom Lane wrote:
>> * Don't we need to fix the NUM_L (currency symbol) case in the
>> same manner? (The NUM_D and NUM_S cases are handled in
>> NUM_numpart_from_char and seem ok at a quick glance.)
> Yes you get the same skipping if you do:
On Sun, Nov 12, 2017 at 7:00 PM, Tom Lane wrote:
> Oliver Ford writes:
>> [ 0001-apply-number-v3.patch ]
>
> I looked at this patch briefly and have a couple of comments:
>
> * It seems entirely wrong to be matching to L_thousands_sep in the
> NUM_COMMA case; that format code is by definition not
Hi,
> Am 13.11.2017 um 16:50 schrieb Dave Page :
>
> It's worth noting though that it is tied into both our existing community
> user account system and our underlying infrastructure. Don't expect a nice
> shiny RPM or DEB that you can just install and run - it would almost
> certainly take a
Dave,
* Dave Page (dp...@pgadmin.org) wrote:
> On Mon, Nov 13, 2017 at 3:39 PM, Stephen Frost wrote:
> > * Alvar C.H. Freude (a...@alvar-freude.de) wrote:
> > > I’m using Sympa for my own mailing lists and are always interested in
> > other alternatives then mailman.
> >
> > Yes, it's actually on
On Mon, Nov 13, 2017 at 3:39 PM, Stephen Frost wrote:
> Greetings,
>
> * Alvar C.H. Freude (a...@alvar-freude.de) wrote:
> > > Am 13.11.2017 um 14:14 schrieb Stephen Frost :
> > >
> > > The changes which we expect to be most significant to users can be
> found
> > > on the wiki here: https://wiki
Greetings,
* Alvar C.H. Freude (a...@alvar-freude.de) wrote:
> > Am 13.11.2017 um 14:14 schrieb Stephen Frost :
> >
> > The changes which we expect to be most significant to users can be found
> > on the wiki here: https://wiki.postgresql.org/wiki/PGLister_Announce the
> > current version of whic
Hi,
> Am 13.11.2017 um 14:14 schrieb Stephen Frost :
>
> The changes which we expect to be most significant to users can be found
> on the wiki here: https://wiki.postgresql.org/wiki/PGLister_Announce the
> current version of which is also included below.
Sorry, this is a little bit off topic, b
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hi Anthony,
Thank you for the new version of the patch! Here
Greetings,
* Tatsuo Ishii (is...@sraoss.co.jp) wrote:
> > This list has now been migrated to new mailing list software known as
> > 'PGLister'. This migration will impact all users of this mailing list
> > in one way or another.
> >
> > If you would like to unsubscribe from this mailing list, pl
On 28 October 2017 at 13:46, Pavel Stehule wrote:
> I though about Alexander proposal, and I am thinking so it can be probably
> best if we respect psql design. I implemented two command suffixes
> (supported only when it has sense) "s" sorted by size and "d" as descent
>
> so list of tables can b
From: Stephen Frost
Subject: Migration to PGLister - After
Date: Mon, 13 Nov 2017 08:14:56 -0500
Message-ID: <20171113131456.gf4...@tamriel.snowman.net>
> Greetings!
>
> This list has now been migrated to new mailing list software known as
> 'PGLister'. This migration will impact all users of t
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> auth-scram.c is visibly not able to do things in a deterministic way,
> that's more determinisitc:
Hah, excellent point, will push in a moment (also to test that the
-committers list is happy with the change to pglister :).
Thanks!
Hi all,
auth-scram.c is visibly not able to do things in a deterministic way,
that's more determinisitc:
--- a/src/backend/libpq/auth-scram.c
+++ b/src/backend/libpq/auth-scram.c
@@ -1116,7 +1116,7 @@ build_server_final_message(scram_state *state)
/*
- * Determinisitcally generate salt for moc
Greetings!
This list has now been migrated to new mailing list software known as
'PGLister'. This migration will impact all users of this mailing list
in one way or another.
If you would like to unsubscribe from this mailing list, please click on
'Show Original' or 'Show Headers' in your client
On Sat, Nov 11, 2017 at 04:34:31PM +0100, Dmitry Dolgov wrote:
> > >
> > > Here isAssignment is unused variable, so it could be removed.
> >
> > In this case I disagree - the purpose of these examples is to show
> everything
> > you can use. So I just need to come up with some example that involves
82 matches
Mail list logo
