pgsql: Fix comment in xlogreader.c

2019-09-25 Thread Michael Paquier
Fix comment in xlogreader.c This has been introduced by 709d003, that has moved readSegNo, readOff and readPageTLI into a new structure called WALOpenSegment initialized separately. Author: Kyotaro Horiguchi Discussion: https://postgr.es/m/[email protected] Branc

Re: pgsql: Implement jsonpath .datetime() method

2019-09-25 Thread Alexander Korotkov
On Thu, Sep 26, 2019 at 2:57 AM Tom Lane wrote: > Alexander Korotkov writes: > > On Thu, Sep 26, 2019 at 2:12 AM Tom Lane wrote: > >> The proximate problem seems to be that compareItems() is insufficiently > >> careful to ensure that both values are non-null before passing them > >> off to datat

Re: pgsql: Implement jsonpath .datetime() method

2019-09-25 Thread Tom Lane
Alexander Korotkov writes: > On Thu, Sep 26, 2019 at 2:12 AM Tom Lane wrote: >> The proximate problem seems to be that compareItems() is insufficiently >> careful to ensure that both values are non-null before passing them >> off to datatype-specific code. The code accidentally fails to crash >>

Re: pgsql: Support reloptions of enum type

2019-09-25 Thread Michael Paquier
Hi Alvaro, On Wed, Sep 25, 2019 at 06:59:24PM +, Alvaro Herrera wrote: > Support reloptions of enum type > > All our current in core relation options of type string (not many, > admittedly) behave in reality like enums. But after seeing an > implementation for enum reloptions, it's clear tha

Re: pgsql: Implement jsonpath .datetime() method

2019-09-25 Thread Alexander Korotkov
On Thu, Sep 26, 2019 at 2:12 AM Tom Lane wrote: > Alexander Korotkov writes: > > I've noticed buildfarm is unhappy with my commits. > > The proximate problem seems to be that compareItems() is insufficiently > careful to ensure that both values are non-null before passing them > off to datatype-s

Re: pgsql: Implement jsonpath .datetime() method

2019-09-25 Thread Tom Lane
Alexander Korotkov writes: > I've noticed buildfarm is unhappy with my commits. The proximate problem seems to be that compareItems() is insufficiently careful to ensure that both values are non-null before passing them off to datatype-specific code. The code accidentally fails to crash on 64-bi

pgsql: Correctly cast types to Datum and back in compareDatetime()

2019-09-25 Thread Alexander Korotkov
Correctly cast types to Datum and back in compareDatetime() Discussion: https://postgr.es/m/CAPpHfdteFKW6MLpXM4md99m55YAuXs0n9_P2wiTq_EmG09doUA%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7881bb14f4b23e8dc8671938cfb3f34117c12d8b Modified Files

Re: pgsql: Implement jsonpath .datetime() method

2019-09-25 Thread Alexander Korotkov
On Thu, Sep 26, 2019 at 12:05 AM Alexander Korotkov < [email protected]> wrote: > > On Wed, Sep 25, 2019 at 10:52 PM Alexander Korotkov > wrote: > > Implement jsonpath .datetime() method > > I've noticed buildfarm is unhappy with my commits. > > 1. https://buildfarm.postgresql.org/cgi-bin/

pgsql: Fix handling of GENERATED columns in CREATE TABLE LIKE INCLUDING

2019-09-25 Thread Tom Lane
Fix handling of GENERATED columns in CREATE TABLE LIKE INCLUDING DEFAULTS. LIKE INCLUDING DEFAULTS tried to copy the attrdef expression without copying the state of the attgenerated column. This is in fact wrong, because GENERATED and DEFAULT expressions are not the same kind of animal; one can c

pgsql: Fix handling of GENERATED columns in CREATE TABLE LIKE INCLUDING

2019-09-25 Thread Tom Lane
Fix handling of GENERATED columns in CREATE TABLE LIKE INCLUDING DEFAULTS. LIKE INCLUDING DEFAULTS tried to copy the attrdef expression without copying the state of the attgenerated column. This is in fact wrong, because GENERATED and DEFAULT expressions are not the same kind of animal; one can c

Re: pgsql: Implement jsonpath .datetime() method

2019-09-25 Thread Alexander Korotkov
On Wed, Sep 25, 2019 at 10:52 PM Alexander Korotkov wrote: > Implement jsonpath .datetime() method I've noticed buildfarm is unhappy with my commits. 1. https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lapwing&dt=2019-09-25%2020%3A40%3A11 2. https://buildfarm.postgresql.org/cgi-bin/show

pgsql: Error suppression support for upcoming jsonpath .datetime() meth

2019-09-25 Thread Alexander Korotkov
Error suppression support for upcoming jsonpath .datetime() method Add support of error suppression in some date and time manipulation functions as it's required for jsonpath .datetime() method support. This commit doesn't use PG_TRY()/PG_CATCH() in order to implement that. Instead, it provides

pgsql: Implement standard datetime parsing mode

2019-09-25 Thread Alexander Korotkov
Implement standard datetime parsing mode SQL Standard 2016 defines rules for handling separators in datetime template strings, which are different to to_date()/to_timestamp() rules. Standard allows only small set of separators and requires strict matching for them. Standard applies to jsonpath .

pgsql: Implement jsonpath .datetime() method

2019-09-25 Thread Alexander Korotkov
Implement jsonpath .datetime() method This commit implements jsonpath .datetime() method as it's specified in SQL/JSON standard. There are no-argument and single-argument versions of this method. No-argument version selects first of ISO datetime formats matching input string. Single-argument ve

pgsql: Allow datetime values in JsonbValue

2019-09-25 Thread Alexander Korotkov
Allow datetime values in JsonbValue SQL/JSON standard allows manipulation with datetime values. So, it appears to be convinient to allow datetime values to be represented in JsonbValue struct. These datetime values are allowed for temporary representation only. During serialization datetime valu

pgsql: Implement parse_datetime() function

2019-09-25 Thread Alexander Korotkov
Implement parse_datetime() function This commit adds parse_datetime() function, which implements datetime parsing with extended features demanded by upcoming jsonpath .datetime() method: * Dynamic type identification based on template string, * Support for standard-conforming 'strict' mode, *

pgsql: Update expected output for dummy_index_am

2019-09-25 Thread Alvaro Herrera
Update expected output for dummy_index_am Forgot to add the file in the previous commit. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/bd29cc1992df9a1b786ca36c05e8f590d3795d10 Modified Files -- .../modules/dummy_index_am/expected/reloptions.out | 26 +

Re: pgsql: Support reloptions of enum type

2019-09-25 Thread Alvaro Herrera
On 2019-Sep-25, Alvaro Herrera wrote: > Support reloptions of enum type I forgot to "git add" an expected output file. Pushing in a minute .. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql: Support reloptions of enum type

2019-09-25 Thread Alvaro Herrera
Support reloptions of enum type All our current in core relation options of type string (not many, admittedly) behave in reality like enums. But after seeing an implementation for enum reloptions, it's clear that strings are messier, so introduce the new reloption type. Switch all string options

pgsql: Split out recovery confing-writing code from pg_basebackup

2019-09-25 Thread Alvaro Herrera
Split out recovery confing-writing code from pg_basebackup ... into a new file, fe_utils/recovery_gen.c. This can later be used by pg_rewind. Authors: Paul Guo, Jimmy Yih, Ashwin Agrawal. A few tweaks by Álvaro Herrera Reviewed-by: Michaël Paquier Discussion: https://postgr.es/m/CAEET0ZEffUkXc