Re: making the backend's json parser work in frontend code
Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
To: Mark Dilger <mark.dilger@enterprisedb.com>
Cc: Robert Haas <robertmhaas@gmail.com>, David Steele <david@pgmasters.net>, Mahendra Singh Thalor <mahi6run@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2020-01-30T06:10:44Z
Lists: pgsql-hackers
Attachments
- v8-0002-Adding-frontend-tests-for-json-parser.patch (text/x-patch) patch v8-0002
On Thu, Jan 30, 2020 at 7:36 AM Mark Dilger
<mark.dilger@enterprisedb.com> wrote:
>
>
>
> > On Jan 29, 2020, at 1:02 PM, Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote:
> >
> > On Wed, Jan 29, 2020 at 4:32 PM Andrew Dunstan
> > <andrew.dunstan@2ndquadrant.com> wrote:
> >>
> >>
> >> On 1/28/20 5:28 PM, Mark Dilger wrote:
> >>>
> >>>
> >>>> +# There doesn't seem to be any easy way to get TestLib to use the binaries from
> >>>> +# our directory, so we hack up a path to our binary and run that
> >>>> directly. This
> >>>> +# seems brittle enough that some other solution should be found, if possible.
> >>>> +
> >>>> +my $test_json = join('/', $ENV{TESTDIR}, 'test_json');
> >>>>
> >>>> I don't know what the right thing to do here is. Perhaps someone more
> >>>> familiar with TAP testing can comment.
> >>> Yeah, I was hoping that might get a comment from Andrew. I think if it works as-is on windows, we could just use it this way until it causes a problem on some platform or other. It’s not a runtime issue, being only a build-time test, and only then when tap tests are enabled *and* running check-world, so nobody should really be adversely affected. I’ll likely get around to testing this on Windows, but I don’t have any Windows environments set up yet, as that is still on my todo list.
> >>>
> >>
> >>
> >> I think using TESTDIR is Ok,
> >
> >
> > I've changed my mind, I don't think that will work for MSVC, the
> > executable gets built elsewhere for that. I'll try to come up with
> > something portable.
>
> I’m just now working on getting my Windows VMs set up with Visual Studio and whatnot, per the wiki instructions, so I don’t need to burden you with this sort of Windows task in the future. If there are any gotchas not mentioned on the wiki, I’d appreciate pointers about how to avoid them. I’ll try to help devise a solution, or test what you come up with, once I’m properly set up for that.
>
> For no particular reason, I chose Windows Server 2019 and Windows 10 Pro.
>
One VM should be sufficient. Either W10Pro os WS2019 would be fine. I
have buildfarm animals running on both.
Here's what I got working after a lot of trial and error. (This will
require a tiny change in the buildfarm script to make the animals test
it). Note that there is one test that I couldn't get working, so I
skipped it. If you can find out why it fails so much the better ... it
seems to be related to how the command processor handles quotes.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Add jsonapi.c to Mkvcbuild.pm's @pgcommonallfiles.
- 006b9dcad419 13.0 landed
-
Move jsonapi.c and jsonapi.h to src/common.
- beb4699091e9 13.0 landed
-
Move some code from jsonapi.c to jsonfuncs.c.
- 73ce2a03f30b 13.0 landed
-
Adjust pg_parse_json() so that it does not directly ereport().
- 1f3a021730be 13.0 landed
-
Remove jsonapi.c's lex_accept().
- 530609aa4263 13.0 landed
-
Split JSON lexer/parser from 'json' data type support.
- 11b5e3e35d39 13.0 landed
-
Rationalize code placement between wchar.c, encnames.c, and mbutils.c.
- 5afaa2e42655 13.0 landed
-
Move wchar.c and encnames.c to src/common/.
- e6afa8918c46 13.0 landed
-
Update header comments for wchar.c and encnames.c.
- 3d4cb5d6c180 13.0 landed
-
Make StringInfo available to frontend code.
- 26aaf97b683d 13.0 cited
-
Use SASLprep to normalize passwords for SCRAM authentication.
- 60f11b87a234 10.0 cited