The PostgreSQL Community Code of Conduct Committee has received a draft of the Russian translation of the Code of Conduct Policy updated August 18, 2020 for review.The English version of the Policy is at:https://www.postgresql.org/about/policies/coc/The translation was created by:Anastasia Raspopin
David,
Thank you -- that is exactly what I needed!
On Fri, Feb 26, 2021 at 2:06 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Fri, Feb 26, 2021 at 12:01 PM Adrian Klaver
> wrote:
>
>> Which refers to COPYRIGHT:
>>
>>
>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob
Hello,
There is a file in my pg_wal directory called
"0001003B00D0.deleted", last modified in December 2020, and
has survived PG & server restarts. I've been having some errors with
WAL files
(https://www.postgresql.org/message-id/flat/095ccf8d-7f58-d928-427c-b17ace23cae6%40burge
=?utf-8?Q?Paul_F=C3=B6rster?= writes:
> sorry, I just realized I used a redundant @ character. So here's the
> corrected version.
Actually we need a patch against the SGML sources, not the generated
files. I took this and marked it up into SGML, and (as usual when
looking at this text, it seems
On Fri, Feb 26, 2021 at 12:01 PM Adrian Klaver
wrote:
> Which refers to COPYRIGHT:
>
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=COPYRIGHT;h=655a3c59d60f54a824cc8ad6c94a4522f2b465cd;hb=HEAD
>
>
The COPYRIGHT file indeed is serving as the in-repo documentation of our
license.
Hi Tom,
> On 26. Feb, 2021, at 19:02, Paul Förster wrote:
>
> as I said, I don't know how to write a patch. But I played around with diff &
> patch.
>
> However, does this do when applied to
> https://www.postgresql.org/docs/current/libpq-connect.html? Would this be
> what is needed?
sorry,
On 2/26/21 10:39 AM, Rumpi Gravenstein wrote:
Tom
Thanks for the quick reply. What you stated is what I was expecting.
I've searched high and low for the documentation that proves that point
-- something I need to do to satisfy our legal team. Any thoughts on
under which rock that license
On 2/26/21 11:39 AM, Rumpi Gravenstein wrote:
Tom
Thanks for the quick reply. What you stated is what I was expecting.
I've searched high and low for the documentation that proves that point
-- something I need to do to satisfy our legal team. Any thoughts on
under which rock that license
Tom
Thanks for the quick reply. What you stated is what I was expecting. I've
searched high and low for the documentation that proves that point --
something I need to do to satisfy our legal team. Any thoughts on under
which rock that license language exists?
Best Regards,
Rumpi
On Thu, Feb
Hi Tom,
> On 26. Feb, 2021, at 17:13, Tom Lane wrote:
>
> WFM. Who's going to write the patch? (I can, but if one of you
> wants to, be my guest.)
as I said, I don't know how to write a patch. But I played around with diff &
patch.
However, does this do when applied to
https://www.postgres
It might be a concern, but generally that should be a row level lock and
only block other update/delete options on those rows. It might be helpful
to look at the explain analyze output early on vs later in the process. It
might be that you are getting very few hot updates and indexes are being
upda
Hi Tom,
> On 26. Feb, 2021, at 17:13, Tom Lane wrote:
>
> WFM. Who's going to write the patch? (I can, but if one of you
> wants to, be my guest.)
I don't know how to write a patch. Is there any documentation about that?
Cheers,
Paul
Alvaro Herrera writes:
> On 2021-Feb-26, Paul Förster wrote:
>> if you remove the outer brackets of host spec, then that means that
>> only the port may be repeated. The repeat is always meant to refer to
>> its immediate preceding argument. The outer brackets make sure that it
>> refers to either
On 2021-Feb-26, Paul Förster wrote:
> Hi Tom,
>
> > On 26. Feb, 2021, at 15:51, Tom Lane wrote:
> >
> > +1. I think you could lose the outer brackets in hostspec in
> > this formulation, ie given that hostspec is already bracketed
> > above, it should be enough to write
> >
> >hostspec is
Hi Tom,
> On 26. Feb, 2021, at 15:51, Tom Lane wrote:
>
> +1. I think you could lose the outer brackets in hostspec in
> this formulation, ie given that hostspec is already bracketed
> above, it should be enough to write
>
>hostspec is [host][:port][,...]
>
> Also, the paramspec is under-
Alvaro Herrera writes:
> I wonder if we shouldn't instead try to break it up in parts that can be
> explained or described separately. This many brackets makes it pretty
> hard to read.
> We could say something like
> postgresql://[userspec@][hostspec][/dbname][?paramspec]
> where
> userspec
Hi Alvaro,
> On 26. Feb, 2021, at 15:30, Alvaro Herrera wrote:
>
> We could say something like
>
> postgresql://[userspec@][hostspec][/dbname][?paramspec]
>
> where
> userspec is user[:password]
> hostspec is [[host][:port]][,...]
> paramspec is param1=value1&...
>
> which makes it easier
On 2021-Feb-25, Paul Förster wrote:
> So, my suggestion is:
>
> postgresql://[user[:password]@][[host][:port]][,...][/dbname][?param1=value1&...]
>
> Still, I think that it's an improvement, because it makes clear that not only
> the port, but also the host may be repeated.
I wonder if we shou
On Fri, 2021-02-26 at 13:12 +0200, Yambu wrote:
> Is there a quick way to list tables used by a function if the function is big
> to search for tables manually?
No.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
Hello
Is there a quick way to list tables used by a function if the function is
big to search for tables manually?
regards
20 matches
Mail list logo