On Fri, Jan 13, 2017 at 7:13 PM, Tom Lane wrote:
> Dilip Kumar writes:
>> ERROR: did not find '}' at end of input node at character 762
>
I could reproduce this error with simple query like:
SELECT * FROM information_schema.role_usage_grants WHERE object_type
LIKE 'FOREIGN%' AND object_name IN
Le 13/01/2017 à 14:09, Michael Paquier a écrit :
> On Fri, Jan 13, 2017 at 5:48 PM, Gilles Darold
> wrote:
>> Le 13/01/2017 à 05:26, Michael Paquier a écrit :
>>> Surely the temporary file of current_logfiles should not be included
>>> in base backups (look at basebackup.c). Documentation needs t
On 1/11/17 11:20 AM, Ryan Murphy wrote:
> Thanks for the review Beena, I'm glad the patch is ready to go!
committed, thanks
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list
On Wed, Jan 11, 2017 at 2:09 AM, Michael Paquier
wrote:
> On Wed, Jan 11, 2017 at 10:06 AM, David Steele
> wrote:
> > On 1/10/17 3:06 PM, Stephen Frost wrote:
> >> * Magnus Hagander (mag...@hagander.net) wrote:
> >>> On Tue, Jan 10, 2017 at 8:03 PM, Robert Haas
> wrote:
> >
> I may be outv
On Tue, Jan 10, 2017 at 3:01 AM, Michael Paquier
wrote:
> On Sat, Jan 7, 2017 at 8:19 PM, Magnus Hagander
> wrote:
> > On Sat, Jan 7, 2017 at 12:31 AM, Michael Paquier <
> michael.paqu...@gmail.com>
> > wrote:
> >> There is something I forgot. With this patch,
> >> FindStreamingStart()@pg_receiv
On Fri, Jan 13, 2017 at 12:49 AM, Jesper Pedersen
wrote:
> Rebased, and removed the compile warn in hashfuncs.c
I did some testing and review for the patch. I did not see any major
issue, but there are few minor cases for which I have few suggestions.
1. Source File : /doc/src/sgml/pageinspect.
On Fri, Jan 13, 2017 at 8:56 PM, Serge Rielau wrote:
>> That's total nonsense.
>>
>> MERGE isn't UPSERT….
>
> Peter,
> you are misreading what I wrote. I did not allege that PostgreSQL did the
> wrong thing. And you are essentially confirming that there was debate and
> MERGE deemed to be not wh
Fabien COELHO writes:
>> It ends up being about 30 fewer lines of code overall, despite there
>> being four places that have to make ad-hoc RawStmt nodes. On the whole
>> I feel like this is cleaner,
> I agree: Better typing, more homogeneous code (PlannedStmt for all),
> less ad-hoc checks t
On Fri, Jan 13, 2017 at 7:58 PM, Anastasia Lubennikova
wrote:
> 27.12.2016 17:33, Amit Kapila:
>
>
> The similar problem has occurred while testing "parallel index only
> scan" patch and Rafia has included the fix in her patch [1] which
> ideally should be included in this patch, so I have copied
On Sun, Jan 15, 2017 at 1:31 AM, Magnus Hagander wrote:
>
>
> On Tue, Jan 10, 2017 at 3:01 AM, Michael Paquier
> wrote:
>> Based on some analysis, it is enough to look at the last 4 bytes of
>> the compressed file to get the size output data with a single call to
>> lseek() and then read(). So as
On Sat, Jan 14, 2017 at 10:02 PM, Gilles Darold
wrote:
> Le 13/01/2017 à 14:09, Michael Paquier a écrit :
>> On Fri, Jan 13, 2017 at 5:48 PM, Gilles Darold
>> wrote:
>>> Le 13/01/2017 à 05:26, Michael Paquier a écrit :
Surely the temporary file of current_logfiles should not be included
>>>
Hi
In last discussion related to PLpgSQL was mentioned weak of stack trace
PLpgSQL. The function parameters are not printed.
CREATE OR REPLACE FUNCTION public.foo(a double precision, b double
precision)
RETURNS double precision
LANGUAGE plpgsql
AS $function$
begin
return 100/a;
end;
$function
12 matches
Mail list logo
