On 08.08.2019 5:40, Craig Ringer wrote:
On Tue, 6 Aug 2019 at 16:32, Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
New version of the patch with several fixes is attached.
Many thanks to Roman Zharkov for testing.
FWIW I still don't understand your argument with rega
Hello all,
Please find attached a trivial patch making a few arrays const (in addition
to the data they point to).
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index f553523857..aafc7187b0 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access
I am Yonathan Misgan from Ethiopia, want to add some functionalities on
PostgreSQL to support Ethiopian locales. I want your advice where I start to
hack the PostgresSQL source code. I have attached some synopsis about the
existing problems of PostgresSQL related with Ethiopian locale specially
Hi Hosoya-san,
I am sorry for so late to reply to you.
I merged the patches into master(commit:
44460d7017cde005d7a2e246db0b32375bfec15d).
I tested the case I used in the previous patches and didn't find any issues.
Now I find that you are rethinking some of the details.
I will cont
чт, 8 авг. 2019 г. в 06:18, Kyotaro Horiguchi :
>
> Hello.
>
> At Wed, 7 Aug 2019 12:14:48 +0300, Dmitry Igrishin wrote
> in
> > > -if ($lib =~ m/\s/)
> > > -{
> > > -$lib = '"' . $lib . """;
> > > -}
> > > +# Since VC automatically quotes paths specified as the data of
>
> > As for the replace comment, I'm not
> > sure it is needed since I think quoting is not the task for
> > AddLibrary/AddIncludeDir in the first place (and AddIncludeDir
> > doesn't have the same comment).
The attached 3rd version of the patch contains no comment in AddLibrary().
Sorry, forgot to
On Wed, 7 Aug 2019 at 21:27, Alvaro Herrera
wrote:
> On 2019-Aug-07, Simon Riggs wrote:
>
> > I saw your recent commit and it scares me in various places, noted below.
> >
> > "Commit: Apply constraint exclusion more generally in partitioning"
> >
> > "This applies particularly to the default par
Hi Amul,
On Thu, Aug 8, 2019 at 4:15 PM amul sul wrote:
>
> Hi,
>
> In RelationBuildPartitionDesc(), a memory space that use to gather
> partitioning
> bound info wasn't free at the end. This might not a problem because this
> allocated memory will eventually be recovered when the top-level con
Hi Ibrar, Thomas and Robert,
On 8/2/19 11:00 PM, Ibrar Ahmed wrote:
> I have rebased the patch and currently reviewing the patch
> on master (1e2fddfa33d3c7cc93ca3ee0f32852699bd3e012).
Thanks a lot for your effort. We are now trying to put again more work
and time in this patch.
We are grateful
Hi Simon,
On Thu, Aug 8, 2019 at 4:54 PM Simon Riggs wrote:
> On Wed, 7 Aug 2019 at 21:27, Alvaro Herrera wrote:
>> Well, yes, avoiding that is the point of this commit also: we were
>> scanning some partitions for some queries, after this patch we're
>> supposed not to.
>
>
> Understood
>
> My
Hi, hackers
"The local variables that do not have the volatile type and have been changed
between the setjmp() invocation and longjmp() call are indeterminate". This is
what the POSIX (and C standard for setjmp) says.
That's fine actually, but if we put the PG_TRY()/CATCH() in a loop, high
versio
On Thu, Aug 8, 2019 at 1:27 PM Amit Langote wrote:
> Hi Amul,
>
> On Thu, Aug 8, 2019 at 4:15 PM amul sul wrote:
> >
> > Hi,
> >
> > In RelationBuildPartitionDesc(), a memory space that use to gather
> partitioning
> > bound info wasn't free at the end. This might not a problem because this
> >
On Thu, Aug 8, 2019 at 7:31 PM Yonatan Misgan wrote:
> I am Yonathan Misgan from Ethiopia, want to add some functionalities on
> PostgreSQL to support Ethiopian locales. I want your advice where I start to
> hack the PostgresSQL source code. I have attached some synopsis about the
> existing pr
On Thu, Aug 8, 2019 at 5:33 PM amul sul wrote:
> On Thu, Aug 8, 2019 at 1:27 PM Amit Langote wrote:
>> Thanks for the patch. This was discussed recently in the "hyrax vs.
>> RelationBuildPartitionDesc()" thread [1] and I think Alvaro proposed
>> an approach that's similar to yours. Not sure wh
Hi!
The patch makes my tests pass.
I wonder about a few things:
- Isn’t there any code that could be re-used for that (the one triggered by ‘a’
< ‘A’ COLLATE ucs_basic)?
- For object key members, the standard also refers to unicode code point
collation (SQL-2:2016 4.46.3, last paragraph).
- I
On Wed, Aug 07, 2019 at 05:54:14PM -0400, Tom Lane wrote:
> Actually, looking in the source code finds
>
> * We allow the user to vacuum or analyze a table if he is superuser, the
> * table owner, or the database owner (but in the latter case, only if
> * it's not a shared relation)
On Wed, Aug 07, 2019 at 12:48:29PM +0300, Liudmila Mantrova wrote:
> If we decide to fix this, we should probably revise and back-patch the whole
> paragraph where it appears as it seems to mix up scanning target cluster
> WALs and applying source cluster WALs. A small patch is attached for your
>
Hello,
On Thu, Aug 8, 2019 at 5:09 PM Amit Langote wrote:
>
> Hi Simon,
>
> On Thu, Aug 8, 2019 at 4:54 PM Simon Riggs wrote:
> > On Wed, 7 Aug 2019 at 21:27, Alvaro Herrera
> > wrote:
> >> Well, yes, avoiding that is the point of this commit also: we were
> >> scanning some partitions for som
On Wed, Aug 7, 2019 at 5:06 PM Thomas Munro wrote:
>
> On Thu, Aug 1, 2019 at 1:22 AM Amit Kapila wrote:
> > On Wed, Jul 31, 2019 at 10:13 AM Amit Kapila
> > wrote:
> > > On Tue, Jul 30, 2019 at 5:26 PM Thomas Munro
> > > wrote:
> > > > but
> > > > here's a small thing: I managed to reach an
Hi,
On Thu, Aug 8, 2019 at 10:10 AM Amit Langote wrote:
> On Wed, Aug 7, 2019 at 6:00 PM Etsuro Fujita wrote:
> > On Wed, Aug 7, 2019 at 4:28 PM Amit Langote wrote:
> > > I just noticed obsolete references to es_result_relation_info that
> > > 0002 failed to remove. One of them is in fdwhandle
Thank you for your quick response. I am also impressed to develop Ethiopian
calendar as an extension on PostgreSQL and I I have already developed the
function that convert Gregorian calendar time to Ethiopian calendar time. But
the difficulty is on how to use this function on PostgreSQL as well
Hi,
On 2019-08-07 14:50:17 +0530, Amit Kapila wrote:
> On Tue, Aug 6, 2019 at 1:26 PM Andres Freund wrote:
> > On 2019-08-05 11:29:34 -0700, Andres Freund wrote:
> > > +/*
> > > + * Binary heap comparison function to compare the time at which an error
> > > + * occurred for transactions.
> > > +
On Tue, 16 Jul 2019 at 13:57, Masahiko Sawada wrote:
>
> On Wed, Jun 12, 2019 at 1:30 PM Masahiko Sawada wrote:
> >
> > Hi all,
> >
> > Long-running vacuum could be sometimes cancelled by administrator. And
> > autovacuums could be cancelled by concurrent processes. Even if it
> > retries after c
On 8/8/19 9:29 AM, Yonatan Misgan wrote:
> From: Thomas Munro
>> Perl, Python etc. If I were you I think I'd experiment with a
>> prototype implementation using PL/Perl, PL/Python etc (a way to
As a bit of subtlety that might matter, the internal representation
in PostgreSQL, as in ISO 8601, ap
A long time ago, we changed LC_COLLATE and LC_CTYPE from cluster-wide to
per-database (61d967498802ab86d8897cb3c61740d7e9d712f6). There is some
leftover code from that in initdb.c and backend/main/main.c to pass
these environment variables around in the expectations that the backend
will write the
Adam Lee writes:
> That's fine actually, but if we put the PG_TRY()/CATCH() in a loop, high
> version gcc might complain.
I'd be inclined to say "so don't do that then". Given this interpretation
(which sure looks like a bug to me, gcc maintainers' opinion or no),
you're basically going to have
Peter Eisentraut writes:
> A long time ago, we changed LC_COLLATE and LC_CTYPE from cluster-wide to
> per-database (61d967498802ab86d8897cb3c61740d7e9d712f6). There is some
> leftover code from that in initdb.c and backend/main/main.c to pass
> these environment variables around in the expectatio
I wrote:
> ... In particular, I'm concerned that this patch will
> result in subtle changes in what settings get chosen during initdb.
OK, after reviewing the code a bit more I take that back --- initdb's
choices are entirely made within initdb.
However, I don't much like the choice to set LC_COL
[ returning to this topic now that the CF is over ]
I wrote:
> Perhaps there's an argument for doing something to change the behavior
> of list_union and list_difference and friends. Not sure --- it could
> be a foot-gun for back-patching. I'm already worried about the risk
> of back-patching co
On 2019-Aug-08, Dmitry Igrishin wrote:
> my $prefixcmd =
> - $solution->{options}->{python} . "\\python -c
> \"$pythonprog\"";
> + "\"$solution->{options}->{python}\\python\" -c
> \"$pythonprog\"";
I think you can make this prettier like this:
my $p
I realize that this has now been sent, but I wanted to comment on one
item:
On 2019-Aug-04, Jonathan S. Katz wrote:
> * Ensure that partition key columns will not be dropped as the result of an
> "indirect drop," such as from a cascade from dropping the key column's data
> type (e.g. a custom dat
+1
Patch successfully applied to the master (
43211c2a02f39d6568496168413dc00e0399dc2e)
On Thu, Aug 8, 2019 at 12:30 PM Mark G wrote:
> Hello all,
>
> Please find attached a trivial patch making a few arrays const (in
> addition to the data they point to).
>
>
>
--
Ibrar Ahmed
On 2019-08-08 08:46, Mark G wrote:
> Please find attached a trivial patch making a few arrays const (in
> addition to the data they point to).
How did you find this? Any special compiler settings?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
Alvaro Herrera writes:
> On 2019-Aug-04, Jonathan S. Katz wrote:
>> * Ensure that partition key columns will not be dropped as the result of an
>> "indirect drop," such as from a cascade from dropping the key column's data
>> type (e.g. a custom data type). This fix is applied only to newly create
On Wed, Aug 7, 2019 at 08:56:18AM -0400, Sehrope Sarkuni wrote:
> On Mon, Aug 5, 2019 at 9:02 PM Bruce Momjian wrote:
>
> On Wed, Jul 31, 2019 at 09:25:01AM -0400, Sehrope Sarkuni wrote:
> > Even if we do not include a separate per-relation salt or things like
> > relfilenode when ge
On Thu, Aug 8, 2019 at 6:29 AM Yonatan Misgan wrote:
> So my question is after developing the converter function where I put it for
> accessing it on PostgreSQL.
Maybe you can take some inspiration from the postgresql-unit extension:
https://github.com/df7cb/postgresql-unit
Note that it is bu
On 8/8/19 2:15 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> On 2019-Aug-04, Jonathan S. Katz wrote:
>>> * Ensure that partition key columns will not be dropped as the result of an
>>> "indirect drop," such as from a cascade from dropping the key column's data
>>> type (e.g. a custom data type).
On Wed, Aug 7, 2019 at 07:40:05PM -0400, Sehrope Sarkuni wrote:
> With the provisos above, yes I think that would work though I don't think it's
> a good idea. Better to start off using the functions directly and then look
> into optimizing only if they're a bottleneck. As a first pass I'd break i
On Tue, Jul 9, 2019 at 11:09:01AM -0400, Bruce Momjian wrote:
> On Tue, Jul 9, 2019 at 10:59:12AM -0400, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > I agree that all of that isn't necessary for an initial implementation,
> > I was rather trying to lay out how we could i
Andres Freund writes:
> On 2019-07-31 19:40:09 -0400, Tom Lane wrote:
>> That makes the other idea (of a foreach-ish macro declaring the
>> listcell value variable) problematic, too :-(.
> Hm. One way partially around that would be using an anonymous struct
> inside the for(). Something like
> #d
On 2019-Aug-08, Jonathan S. Katz wrote:
> I modified the copy of the announcement on the website to include the
> pg_upgrade option.
>
> https://www.postgresql.org/about/news/1960/
Ooh, had I thought you were going to do that, I would have told you
about the item ending in a comma :-)
--
Álvar
On 8/8/19 2:40 PM, Alvaro Herrera wrote:
> On 2019-Aug-08, Jonathan S. Katz wrote:
>
>> I modified the copy of the announcement on the website to include the
>> pg_upgrade option.
>>
>> https://www.postgresql.org/about/news/1960/
>
> Ooh, had I thought you were going to do that, I would have told
On 2019-Aug-08, Jonathan S. Katz wrote:
> On 8/8/19 2:40 PM, Alvaro Herrera wrote:
> > On 2019-Aug-08, Jonathan S. Katz wrote:
> >
> >> I modified the copy of the announcement on the website to include the
> >> pg_upgrade option.
> >>
> >> https://www.postgresql.org/about/news/1960/
> >
> > Ooh,
On 8/8/19 2:45 PM, Alvaro Herrera wrote:
> On 2019-Aug-08, Jonathan S. Katz wrote:
>
>> On 8/8/19 2:40 PM, Alvaro Herrera wrote:
>>> On 2019-Aug-08, Jonathan S. Katz wrote:
>>>
I modified the copy of the announcement on the website to include the
pg_upgrade option.
https://www.
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Jul 9, 2019 at 11:09:01AM -0400, Bruce Momjian wrote:
> > On Tue, Jul 9, 2019 at 10:59:12AM -0400, Stephen Frost wrote:
> > > * Bruce Momjian (br...@momjian.us) wrote:
> > > I agree that all of that isn't necessary for an initial imp
чт, 8 авг. 2019 г. в 20:07, Alvaro Herrera :
>
> On 2019-Aug-08, Dmitry Igrishin wrote:
>
> > my $prefixcmd =
> > - $solution->{options}->{python} . "\\python -c
> > \"$pythonprog\"";
> > + "\"$solution->{options}->{python}\\python\" -c
> > \"$pythonprog\
On 2019-Aug-08, Amit Langote wrote:
> On Thu, Aug 8, 2019 at 6:22 AM Tom Lane wrote:
> > OK, but maybe also s/created as a default partition/created as the default
> > partition/ ? Writing "a" carries the pretty clear implication that there
> > can be more than one, and contradicting that a sen
On Thu, Aug 8, 2019 at 8:51 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> How did you find this? Any special compiler settings?
>
16 hours stuck in a plane on an international flight. I was just eyeballing
the code to kill the boredom.
-Mark
On Thu, Aug 8, 2019 at 9:31 AM Andres Freund wrote:
> I know that Robert is working on a patch that revises the undo request
> layer somewhat, it's possible that this is best discussed afterwards.
Here's what I have at the moment. This is not by any means a complete
replacement for Amit's undo w
Hi, Markus!
On Thu, Aug 8, 2019 at 11:53 AM Markus Winand wrote:
> The patch makes my tests pass.
Cool.
> I wonder about a few things:
>
> - Isn’t there any code that could be re-used for that (the one triggered by
> ‘a’ < ‘A’ COLLATE ucs_basic)?
PostgreSQL supports ucs_basic, but it's alias
On Thu, Aug 8, 2019 at 8:25 PM Ibrar Ahmed wrote:
> +1
>
> Patch successfully applied to the master (
> 43211c2a02f39d6568496168413dc00e0399dc2e)
>
That change looks like an unrelated patch for initdb. I'm still not seeing
my patch there.
-Mark
On Fri, Aug 9, 2019 at 1:25 AM Mark G wrote:
>
>
> On Thu, Aug 8, 2019 at 8:25 PM Ibrar Ahmed wrote:
>
>> +1
>>
>> Patch successfully applied to the master (
>> 43211c2a02f39d6568496168413dc00e0399dc2e)
>>
>
> That change looks like an unrelated patch for initdb. I'm still not seeing
> my patch
I wrote:
> BTW, further on the subject of performance --- I'm aware of at least
> these topics for follow-on patches:
> * Fix places that are maintaining arrays parallel to Lists for
> access-speed reasons (at least simple_rte_array, append_rel_array,
> es_range_table_array).
Attached is a patch
On Fri, Aug 9, 2019 at 6:19 AM Peter Geoghegan wrote:
> On Thu, Aug 8, 2019 at 6:29 AM Yonatan Misgan wrote:
> > So my question is after developing the converter function where I put it
> > for accessing it on PostgreSQL.
>
> Maybe you can take some inspiration from the postgresql-unit extensio
On Thu, Aug 08, 2019 at 03:07:59PM -0400, Stephen Frost wrote:
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
On Tue, Jul 9, 2019 at 11:09:01AM -0400, Bruce Momjian wrote:
> On Tue, Jul 9, 2019 at 10:59:12AM -0400, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > I
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On Thu, Aug 08, 2019 at 03:07:59PM -0400, Stephen Frost wrote:
> >* Bruce Momjian (br...@momjian.us) wrote:
> >>On Tue, Jul 9, 2019 at 11:09:01AM -0400, Bruce Momjian wrote:
> >>> On Tue, Jul 9, 2019 at 10:59:12AM -0400, Stephen F
Libpq doesn't have a way to control which password protocols are used.
For example, the client might expect the server to be using SCRAM, but
it actually ends up using plain password authentication instead.
This patch adds:
password_protocol = {plaintext|md5|scram-sha-256|scram-sha-256-plus}
a
On Thu, Aug 8, 2019 at 03:07:59PM -0400, Stephen Frost wrote:
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Tue, Jul 9, 2019 at 11:09:01AM -0400, Bruce Momjian wrote:
> > > On Tue, Jul 9, 2019 at 10:59:12AM -0400, Stephen Frost wrote:
> > > > * Bruce Momjian (br...@momjian.u
Hi Jeevan,
I have reviewed the backup part at code level and still looking into the
restore(combine) and functional part of it. But, here are my comments so
far:
The patches need rebase.
+ if (!XLogRecPtrIsInvalid(previous_lsn))
+
On Fri, 9 Aug 2019 at 04:24, Tom Lane wrote:
> I wrote:
> > Perhaps there's an argument for doing something to change the behavior
> > of list_union and list_difference and friends. Not sure --- it could
> > be a foot-gun for back-patching. I'm already worried about the risk
> > of back-patching
On Fri, 9 Aug 2019 at 09:55, Tom Lane wrote:
> Attached is a patch that removes simple_rte_array in favor of just
> accessing the query's rtable directly. I concluded that there was
> not much point in messing with simple_rel_array or append_rel_array,
> because they are not in fact just mirrors
On Thu, Aug 8, 2019 at 06:31:42PM -0400, Stephen Frost wrote:
> > >Crash recovery doesn't happen "all the time" and neither does vacuum
> > >freeze, and autovacuum processes are independent of individual client
> > >backends- we don't need to (and shouldn't) have the keys in shared
> > >memory.
>
Fujita-san,
On Thu, Aug 8, 2019 at 9:49 PM Etsuro Fujita wrote:
> On Thu, Aug 8, 2019 at 10:10 AM Amit Langote wrote:
> > Attached updated patches; only 0001 changed in this version.
>
> Thanks for the updated version, Amit-san! I updated the 0001 patch a
> bit further:
>
> * Tweaked comments i
Hello.
At Thu, 08 Aug 2019 12:15:38 +0900 (Tokyo Standard Time), Kyotaro Horiguchi
wrote in
<20190808.121538.87367461.horikyota@gmail.com>
> At Wed, 7 Aug 2019 12:14:48 +0300, Dmitry Igrishin wrote
> in
> > > -if ($lib =~ m/\s/)
> > > -{
> > > -$lib = '"' . $lib . """;
>
On Wed, Aug 07, 2019 at 10:10:36AM +0900, Michael Paquier wrote:
> Thanks for the review, Bruce! Tom, do you have any objections?
hearing nothing but cicadas from outside, applied. There were some
warnings I missed with the first version, which are fixed.
--
Michael
signature.asc
Description:
On Thu, Aug 8, 2019 at 2:16 PM Bruce Momjian wrote:
> On Wed, Aug 7, 2019 at 08:56:18AM -0400, Sehrope Sarkuni wrote:
> > Simplest approach for derived keys would be to use immutable attributes
> of the
> > WAL files as an input to the key derivation. Something like HKDF(MDEK,
> "WAL:" |
>
> So,
On Thu, Aug 8, 2019 at 6:31 PM Stephen Frost wrote:
> Strictly speaking, that isn't actually crash recovery, it's physical
> replication / HA, and while those are certainly nice to have it's no
> guarantee that they're required or that you'd want to have the same keys
> for them- conceptually, at
On Thu, Aug 08, 2019 at 10:46:07PM +0300, Dmitry Igrishin wrote:
> This looks nice for a Perl hacker :-). As for me, it looks unusual and
> a bit confusing. I never
> programmed in Perl, but I was able to quickly understand where the
> problem lies due to the
> style adopted in other languages, wh
On Thu, Aug 08, 2019 at 03:38:20PM -0700, Jeff Davis wrote:
> Libpq doesn't have a way to control which password protocols are used.
> For example, the client might expect the server to be using SCRAM, but
> it actually ends up using plain password authentication instead.
Thanks for working on thi
Sorry for being late. I found it is committed before I caught up
this thread again..
At Thu, 8 Aug 2019 14:50:54 +0900, Amit Langote wrote
in
> Hi Alvaro,
>
> On Thu, Aug 8, 2019 at 5:27 AM Alvaro Herrera
> wrote:
> > On 2019-Aug-07, Simon Riggs wrote:
> > > I saw your recent commit and it s
On Fri, Aug 9, 2019 at 1:57 AM Robert Haas wrote:
>
> On Thu, Aug 8, 2019 at 9:31 AM Andres Freund wrote:
> > I know that Robert is working on a patch that revises the undo request
> > layer somewhat, it's possible that this is best discussed afterwards.
>
> Here's what I have at the moment. Thi
Horiguchi-san,
Thanks for the review.
On Fri, Aug 9, 2019 at 12:09 PM Kyotaro Horiguchi
wrote:
> At Thu, 8 Aug 2019 14:50:54 +0900, Amit Langote wrote:
> > When working on it, I realized
> > that the way RelOptInfo.partition_qual is processed is a bit
> > duplicative, so I created a separate pat
On Wed, Aug 07, 2019 at 10:17:25AM -0400, Tom Lane wrote:
> Not objecting to the patch, exactly, just feeling like there's
> more here than meets the eye. Not quite sure if it's worth
> investigating closer, or what we'd even need to do to do so.
Yes, something's weird here. I'd think that the i
On Fri, Aug 9, 2019 at 1:17 PM Amit Langote wrote:
> On Fri, Aug 9, 2019 at 12:09 PM Kyotaro Horiguchi
> wrote:
> > At Thu, 8 Aug 2019 14:50:54 +0900, Amit Langote wrote:
> > > When working on it, I realized
> > > that the way RelOptInfo.partition_qual is processed is a bit
> > > duplicative, so
On Thu, 8 Aug 2019 at 15:03, Konstantin Knizhnik
wrote:
>
>
> On 08.08.2019 5:40, Craig Ringer wrote:
>
> On Tue, 6 Aug 2019 at 16:32, Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> wrote:
>
>> New version of the patch with several fixes is attached.
>> Many thanks to Roman Zharkov for testin
At Fri, 9 Aug 2019 14:02:36 +0900, Amit Langote wrote
in
> On Fri, Aug 9, 2019 at 1:17 PM Amit Langote wrote:
> > On Fri, Aug 9, 2019 at 12:09 PM Kyotaro Horiguchi
> > wrote:
> > > At Thu, 8 Aug 2019 14:50:54 +0900, Amit Langote wrote:
> > > > When working on it, I realized
> > > > that the wa
Can I implement it as a locale support? When the user want to change the lc
_time = am_ET(Amharic Ethiopia ) the date and time representation of the
database systems be in Ethiopian calendar.
Original message
From: Thomas Munro
Date: 8/9/19 1:17 AM (GMT+03:00)
To: Peter Geogh
On Fri, 2019-08-09 at 12:00 +0900, Michael Paquier wrote:
> What about auth_protocol then? It seems to me that it could be
> useful
> to have the restriction on AUTH_REQ_MD5 as well.
auth_protocol does sound like a good name. I'm not sure what you mean
regarding MD5 though.
> This makes it sound
пт, 9 авг. 2019 г. в 05:45, Michael Paquier :
>
> On Thu, Aug 08, 2019 at 10:46:07PM +0300, Dmitry Igrishin wrote:
> > This looks nice for a Perl hacker :-). As for me, it looks unusual and
> > a bit confusing. I never
> > programmed in Perl, but I was able to quickly understand where the
> > probl
79 matches
Mail list logo
