On Fri, Nov 4, 2016 at 6:33 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 6/7/16 2:43 PM, Peter Eisentraut wrote:
> > On 6/7/16 1:19 AM, Haribabu Kommi wrote:
> >> How about the following case, Do we treat them as same or different?
> >>
> >> select 'fe80::%eth1'::inet = 'fe
On Mon, Nov 7, 2016 at 10:46 AM, Tsunakawa, Takayuki
wrote:
>
> The third paragraph may be redundant, I'm a bit inclined to leave it for
> kindness and completeness. The attached revised patch just correct the
> existing typo (large -> larger).
>
I am not agree to having this paragraph either,
From: amul sul [mailto:sula...@gmail.com]
> IMHO, I think we could remove third paragraph completely and generalised
> starting of second paragraph, somewhat looks likes as
> follow:
>
>
> -If you have a dedicated database server with 1GB or more of RAM,
> a
> -reasonable
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Ashutosh Bapat
> I am not sure if following condition is a good idea in ServerLoop()
> 1650 if (pmState == PM_WAIT_DEAD_END || ClosedSockets)
>
> There are no sockets to listen on, so select
2016-11-07 2:16 GMT+01:00 Tom Lane :
> The intent of SPI_push/SPI_pop seems to be to draw a boundary line between
> nested layers of SPI callers. Which is fine, but the SPI_connect and
> SPI_finish calls of the inner layer would suffice for that. AFAICS,
> the only thing that SPI_push/SPI_pop bu
On Mon, Nov 7, 2016 at 12:36 PM, Haribabu Kommi
wrote:
> The added regression test fails for the cases where the server is loaded
> with
> different pg_hba.conf rules during installcheck verification. Updated patch
> is
> attached with removing those tests.
That's not a full review as I just glan
On Fri, Oct 28, 2016 at 4:55 PM, Haribabu Kommi
wrote:
>
>
> On Fri, Oct 28, 2016 at 4:17 AM, Alvaro Herrera
> wrote:
>
>> Greg Stark wrote:
>>
>> > The fundamental problem is that the pga_hba.conf file has some bits of
>> > complex structure that aren't easily captured by linear arrays. The
>>
On Mon, Nov 7, 2016 at 8:40 AM, Shay Rojansky wrote:
> > 1. Does everyone agrees that renaming the existing datatype without
>> > changing the OID?
>> >
>> >
>> > As I said before, Npgsql for one loads data types by name, not by OID.
>> > So this would definitely cause breakage.
>>
>> Why
On 2016/11/04 22:04, Robert Haas wrote:
On Fri, Nov 4, 2016 at 7:20 AM, Etsuro Fujita
wrote:
I found another typo in postgres_fdw.c. Attached is a patch for fixing
that.
OK, committed that, too.
Thanks again!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-h
On 2016/11/04 19:55, Etsuro Fujita wrote:
Attached is an updated version of the patch.
I noticed that I have included an unrelated regression test in the
patch. Attached is a patch with the test removed.
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/deparse.c
--- b/contrib/postgres
Thanks for the review! I have fixed all your feedback in the attached patch.
On 11/03/2016 04:24 PM, Michael Banck wrote:
It does not update the documentation, I think at least section 18.9
"Secure TCP/IP Connections with SSL" needs updating as it says: "The
files server.key, server.crt, root.cr
On Sun, Nov 6, 2016 at 1:13 PM, Tom Lane wrote:
>
> > The original intent of that patch tried to cover the case where we insert
> > records
> > made of dozens columns sharing the same type definition, and trying to
> > understand
> > what is going on, at a glance, when we debugged something like t
The intent of SPI_push/SPI_pop seems to be to draw a boundary line between
nested layers of SPI callers. Which is fine, but the SPI_connect and
SPI_finish calls of the inner layer would suffice for that. AFAICS,
the only thing that SPI_push/SPI_pop buy for us is the ability to detect
a missing SP
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
> On Sun, Nov 6, 2016 at 6:30 PM, MauMau wrote:
> > Sorry, I may have had to send this to pgsql-hackers. I just replied
> > to all, which did not include pgsql-hackers but pgsql-bug
On Mon, Jul 4, 2016 at 2:30 AM, Heikki Linnakangas wrote:
> I think we should pack the TIDs more tightly, like GIN does with the varbyte
> encoding. It's tempting to commit this without it for now, and add the
> compression later, but I'd like to avoid having to deal with multiple
> binary-format
>
> > 1. Does everyone agrees that renaming the existing datatype without
> > changing the OID?
> >
> >
> > As I said before, Npgsql for one loads data types by name, not by OID.
> > So this would definitely cause breakage.
>
> Why would that cause breakage?
Well, the first thing Npgsql d
Franck Verrot writes:
> On Sat, Nov 5, 2016 at 11:13 AM, Tom Lane wrote:
>> The cases that are successfully annotated by the current patch seem to
>> mostly already have error cursor information, which really is good enough
>> IMO --- you can certainly figure out which column corresponds to the
>
On Sat, Nov 5, 2016 at 11:13 AM, Tom Lane wrote:
>
> The cases that are successfully annotated by the current patch seem to
> mostly already have error cursor information, which really is good enough
> IMO --- you can certainly figure out which column corresponds to the
> textual spot that the cur
I wrote:
> I got the code to a state that I liked (attached), and started reviewing
> the docs, and then it occurred to me to wonder why you'd chosen to use
> Tcl lists to represent composite output values. The precedent established
> by input argument handling is that composites are transformed t
Hello,
2016-09-12 16:16 GMT+03:00 Dagfinn Ilmari Mannsåker :
>
> I've added it to the 2016-11 commit fest:
> https://commitfest.postgresql.org/11/795/
>
> - ilmari
I've tested your patch.
Patch was applied to the master. It seems there is no need to rebase
it. PostgreSQL was compiled without err
Thank you for your comments,
2016-11-04 20:36 GMT+02:00 Tom Lane :
>
> Artur Zakirov writes:
> > I attached new version of the patch, which fix is_char_separator()
> > declaration too.
>
> I did some experimenting using
> http://rextester.com/l/oracle_online_compiler
>
>
> which makes it look a
On Sun, Nov 6, 2016 at 6:30 PM, MauMau wrote:
> Sorry, I may have had to send this to pgsql-hackers. I just replied
> to all, which did not include pgsql-hackers but pgsql-bugs because
> this discussion was on pgsql-bugs. CommitFest app doesn't seem to
> reflect the mails on pgsql-bugs, so I'm r
On Fri, Nov 4, 2016 at 12:36 AM, Robert Haas wrote:
> On Tue, Nov 1, 2016 at 3:48 PM, Haribabu Kommi
> wrote:
> https://commitfest.postgresql.org/11/604/ - pgwin32_is_service not
> checking if SECURITY_SERVICE_SID is disabled
This is quite a particular fix in a particular context. This is as
we
Hello,
Sorry, I may have had to send this to pgsql-hackers. I just replied
to all, which did not include pgsql-hackers but pgsql-bugs because
this discussion was on pgsql-bugs. CommitFest app doesn't seem to
reflect the mails on pgsql-bugs, so I'm re-submitting this here on
pgsql-hackers.
From:
24 matches
Mail list logo