Hello hackers,
Please consider fixing the next batch of typos and inconsistencies in
the tree:
6.1. FADVISE_WILLNEED -> POSIX_FADV_WILLNEED
6.2. failOK -> missing_ok
6.3. failOnerror -> failOnSignal
6.4. fakebits -> remove (irrelevant since introduction in 945543d9)
6.5. FastPathGetLockEntry ->
On Tue, Jul 9, 2019 at 8:30 AM Konstantin Knizhnik
wrote:
Rebased version of the patch is attached.
Thanks for including nice documentation in the patch, which gives a
good overview of what's going on. I haven't read any code yet, but I
took it for a quick drive to understand the user
On Sun, Jul 14, 2019 at 12:44 AM Thomas Munro wrote:
> Even though !(X || Y) is equivalent to !X && !Y, by my reading of
> range_in(), lower.value can be uninitialised when lower.infinite is
> true, and it's also a bit hard to read IMHO, so I'd probably write
> that as !upper.infinite &&
On Tue, Apr 9, 2019 at 3:58 AM Fabien COELHO wrote:
> The attached patch does $SUBJECT, as a showcase for recently added
> features, including advanced expressions (CASE...), \if, \gset, ending SQL
> commands at ";"...
Hi Fabien,
+ the account branch has a 15% probability to be in the same
On Fri, Jul 12, 2019 at 1:42 AM Surafel Temesgen wrote:
> Here are the patch that contain all the comment given except adding a way to
> specify
> to ignoring all error because specifying a highest number can do the work and
> may be
> try to store such badly structure data is a bad idea
Hi
On Sat, Jul 13, 2019 at 06:32:41PM -0500, Michael Glaesemann wrote:
>
>
> > On 2019–07–05, at 12:14, Corey Huinker wrote:
> >
> > In doing that work, it became clear that the command was serving two
> > masters:
> > 1. A desire to see the underlying nuts and bolts of a given database object.
On Wed, Jul 03, 2019 at 02:22:09PM -0700, Melanie Plageman wrote:
On Tue, Jun 18, 2019 at 3:24 PM Melanie Plageman
wrote:
These questions will probably make a lot more sense with corresponding
code, so I will follow up with the second version of the state machine
patch once I finish it.
I
> On 2019–07–05, at 12:14, Corey Huinker wrote:
>
> In doing that work, it became clear that the command was serving two masters:
> 1. A desire to see the underlying nuts and bolts of a given database object.
> 2. A desire to essentially make the schema portion of pg_dump a server side
>
Hi Fabien,
Attached is doc_base64_v10.patch
On Fri, 12 Jul 2019 15:58:21 +0200 (CEST)
Fabien COELHO wrote:
> >> I suggested "Function <>decode ...", which is the kind of thing
> >> we do in academic writing to improve precision, because I thought
> >> it could be better:-)
> >
> > "Function
On Sat, Jul 13, 2019 at 02:41:34PM -0400, Joe Conway wrote:
On 7/13/19 9:38 AM, Joe Conway wrote:
On 7/11/19 9:05 PM, Bruce Momjian wrote:
On Thu, Jul 11, 2019 at 08:41:52PM -0400, Joe Conway wrote:
On 7/11/19 6:37 PM, Bruce Momjian wrote:
> Our first implementation will encrypt the entire
On Sat, Jul 13, 2019 at 11:39:55AM -0400, Tom Lane wrote:
Tomas Vondra writes:
On Thu, Jul 11, 2019 at 05:08:22PM +0200, Tomas Vondra wrote:
On Wed, Jul 10, 2019 at 06:48:16PM -0400, Tom Lane wrote:
The right way to determine operator semantics is to look to see
whether they are in a btree
Martijn van Oosterhout writes:
> Please find attached updated versions of the patches, I've now tested
> them. Also attached is a reproduction script to verify that they
> actually work.
I looked through these (a bit cursorily).
I'm generally on board with the idea of 0001, but not with the
On 7/13/19 9:38 AM, Joe Conway wrote:
> On 7/11/19 9:05 PM, Bruce Momjian wrote:
>> On Thu, Jul 11, 2019 at 08:41:52PM -0400, Joe Conway wrote:
>>> On 7/11/19 6:37 PM, Bruce Momjian wrote:
>>> > Our first implementation will encrypt the entire cluster. We can later
>>> > consider encryption per
Hello Peter,
I think pg_dump/t/002_pg_dump.pl might be a good place. Not the easiest
program in the world to work with, admittedly.
Updated patch with test and expanded documentation.
Patch v2 applies cleanly, compiles, make check-world ok with tap enabled.
Doc gen ok.
The addition
On Sat, Jul 13, 2019 at 2:44 PM Peter Eisentraut
wrote:
>
> On 2019-07-11 21:34, Julien Rouhaud wrote:
> >> Note that with this change, running initdb without arguments will now
> >> error on those platforms: You need to supply either a password or select
> >> a different default authentication
David Rowley writes:
> Thanks for the speedy turnaround. I've looked at v8, as far as a diff
> between the two patches and I'm happy.
> I've marked as ready for committer.
So ... last chance for objections?
I see from the cfbot that v8 is already broken (new call of lnext
to be fixed). Don't
Tomas Vondra writes:
> On Thu, Jul 11, 2019 at 05:08:22PM +0200, Tomas Vondra wrote:
>> On Wed, Jul 10, 2019 at 06:48:16PM -0400, Tom Lane wrote:
>>> The right way to determine operator semantics is to look to see
>>> whether they are in a btree opclass. That's what the rest of the
>>> planner
Hello Thomas,
pg_stat_statements.c:1024:11: error: implicit declaration of function
'pg_strtouint64' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
rows = pg_strtouint64(completionTag + 5, NULL, 10);
^
Apparently it needs to
Hello Jose,
Considering the later arguments on-list, I plan on submitting a more
elaborate patchset integrating the feedback received so far, and along the
following lines:
- uuid type, v4 generation and uuid_version() in core
- Provide a means to rename/supercede extensions keeping
Tomas Vondra writes:
> On Fri, Jul 12, 2019 at 07:59:13PM -0400, Tom Lane wrote:
>> I'm pretty sure this change has been proposed before, and rejected before.
>> Has anybody excavated in the archives for prior discussions?
> Yes, I've done some quick searches like "volatile constraint" and so
Hello Peter,
About doc: I'd consider "generation" instead of "generating" as a
secondary index term.
We do use the "-ing" form for other secondary index terms. It's useful
because the concatenation of primary and secondary term should usually
make a phrase of some sort. The alternative
On 7/11/19 9:05 PM, Bruce Momjian wrote:
> On Thu, Jul 11, 2019 at 08:41:52PM -0400, Joe Conway wrote:
>> On 7/11/19 6:37 PM, Bruce Momjian wrote:
>> > Our first implementation will encrypt the entire cluster. We can later
>> > consider encryption per table or tablespace. It is unclear if
>> >
On Fri, May 3, 2019 at 12:49 AM Laurenz Albe wrote:
> > I propose the attached patch which fixes the problem.
Hi Laurenz,
I agree that the patch makes the code match the documentation. The
documented behaviour seems to make more sense than the code, since
unpatched master gives this nonsense
On 2019-07-11 21:34, Julien Rouhaud wrote:
>> Note that with this change, running initdb without arguments will now
>> error on those platforms: You need to supply either a password or select
>> a different default authentication method.
> Should we make this explicitly stated in the
On 2019-07-13 08:08, Fabien COELHO wrote:
> About doc: I'd consider "generation" instead of "generating" as a
> secondary index term.
We do use the "-ing" form for other secondary index terms. It's useful
because the concatenation of primary and secondary term should usually
make a phrase of
On 7/12/19 2:45 PM, Bruce Momjian wrote:
> On Fri, Jul 12, 2019 at 12:41:19PM -0600, Ryan Lambert wrote:
>> >> I vote for AES 256 rather than 128.
>> >
>> > Why? This page seems to think 128 is sufficient:
>> >
>> > https://crypto.stackexchange.com/questions/20/
>>
On Mon, Jul 8, 2019 at 3:22 PM Thomas Munro wrote:
> Here's some semi-automated feedback, noted while going through
> failures on cfbot.cputube.org. You have a stray editor file
> src/backend/parser/parse_node.c.~1~. Something is failing to compile
> while doing the temp-install in make
On Fri, Jul 12, 2019 at 7:08 PM Robert Haas wrote:
>
> On Fri, Jul 12, 2019 at 5:40 AM Amit Kapila wrote:
>
> > Apart from this, the duplicate key (ex. for size queues the size of
> > two requests can be same) handling might need some work. Basically,
> > either special combine function needs
On Fri, Jul 12, 2019 at 05:01:41PM +0900, Michael Paquier wrote:
> I would also patch GetFakeConfigure in Solution.pm (no need to send a
> new patch), and I thought that you'd actually do the change. What do
> you think?
OK, applied as I have been able to look at it again, and after fixing
the
Hello Jose,
Got it, and done. Please find attached a v2 patch with the upgrade script
included.
Patch v2 applies cleanly. Compiles cleanly (once running configure
--with-uuid=...). Local make check ok. Doc build ok.
There are no tests, I'd suggest to add some under sql & change expected
On Tue, Jun 18, 2019 at 2:41 AM Peter Eisentraut
wrote:
> A small new feature in SQL:2016 allows attaching a table alias to a
> JOIN/USING construct:
>
> ::=
> USING
> [ AS ]
>
> (The part in brackets is new.)
>
> This seems quite useful, and it seems the code would already
Hello Peter,
A possible option 3 is to keep the function in pgcrypto but change
its C code to call the core code.
Updated patch with this change included.
Patch applies cleanly, compiles (both pg and pgcrypto). make check (global
and pgcrypto) ok. Doc generation ok. Minor comments:
32 matches
Mail list logo
