On Thu, Jan 30, 2020 at 7:36 AM Mark Dilger
wrote:
>
>
>
> > On Jan 29, 2020, at 1:02 PM, Andrew Dunstan
> > wrote:
> >
> > On Wed, Jan 29, 2020 at 4:32 PM Andrew Dunstan
> > wrote:
> >>
> >>
> >> On 1/28/20 5:28 PM, Mark Dilger wrote:
> >>>
> >>>
> +# There doesn't seem to be any easy way
> On Jan 29, 2020, at 1:02 PM, Andrew Dunstan
> wrote:
>
> On Wed, Jan 29, 2020 at 4:32 PM Andrew Dunstan
> 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
On Wed, Jan 29, 2020 at 4:32 PM Andrew Dunstan
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
> >> +#
On Wed, Jan 29, 2020 at 10:48 AM Robert Haas wrote:
> Hrrm, OK. I think it must need a sprinkling of Windows-specific magic.
I see that the patch Andrew posted earlier adjusts Mkvcbuild.pm's
@pgcommonallfiles, so I pushed that fix. The other hunks there should
go into the patch to add a test_json
On Wed, Jan 29, 2020 at 10:45 AM Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Jan 28, 2020 at 5:35 PM Mark Dilger
> > wrote:
> >> I merged these a bit. See v7-0001 for details.
>
> > I jiggered that a bit more and committed this. I couldn't see the
> > point of having both the FRONTEND and
Robert Haas writes:
> On Tue, Jan 28, 2020 at 5:35 PM Mark Dilger
> wrote:
>> I merged these a bit. See v7-0001 for details.
> I jiggered that a bit more and committed this. I couldn't see the
> point of having both the FRONTEND and non-FRONTEND code include
> pg_wchar.h.
First buildfarm repor
On Tue, Jan 28, 2020 at 5:35 PM Mark Dilger
wrote:
> I merged these a bit. See v7-0001 for details.
I jiggered that a bit more and committed this. I couldn't see the
point of having both the FRONTEND and non-FRONTEND code include
pg_wchar.h.
I'll wait to see what you make of Andrew's latest com
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
>> pos
Thanks for your review. I considered all of this along with your review
comments in another email prior to sending v7 in response to that other email a
few minutes ago.
> On Jan 28, 2020, at 7:17 AM, Robert Haas wrote:
>
> On Mon, Jan 27, 2020 at 3:05 PM Mark Dilger
> wrote:
>> I’m attaching
> On Jan 28, 2020, at 8:32 AM, Robert Haas wrote:
>
> On Mon, Jan 27, 2020 at 3:05 PM Mark Dilger
> wrote:
>> Since you’ve committed your 0004 and 0005 patches, this v6 patch set is now
>> based on a fresh copy of master.
>
> I think the first question for 0005 is whether want this at all.
>
Robert Haas writes:
> On Tue, Jan 28, 2020 at 2:29 PM Tom Lane wrote:
>> Well, yeah, that's exactly my point. But in my book, "refuse to do
>> anything" should be "elog(ERROR)", not "invoke undefined behavior".
>> An actual abort() call might be all right here, in that at least
>> we'd know what
On Tue, Jan 28, 2020 at 2:29 PM Tom Lane wrote:
> Well, yeah, that's exactly my point. But in my book, "refuse to do
> anything" should be "elog(ERROR)", not "invoke undefined behavior".
> An actual abort() call might be all right here, in that at least
> we'd know what would happen and we could
Robert Haas writes:
> On Tue, Jan 28, 2020 at 1:32 PM Tom Lane wrote:
>> BTW, now that I think about it, CreateDestReceiver is not up to project
>> standards anyway, in that it fails to provide reasonable behavior in
>> the case where what's passed is not a legal value of the enum.
> Well, I mig
On Tue, Jan 28, 2020 at 1:32 PM Tom Lane wrote:
> BTW, now that I think about it, CreateDestReceiver is not up to project
> standards anyway, in that it fails to provide reasonable behavior in
> the case where what's passed is not a legal value of the enum.
> What you'll get, if you're lucky, is a
I wrote:
> Robert Haas writes:
>> Is the example of CreateDestReceiver() sufficient to show that this is
>> not a problem in practice?
> Dunno. I don't see any warnings about that in the buildfarm, but
> that's not a very large sample of non-gcc compilers.
BTW, now that I think about it, Create
Robert Haas writes:
> On Tue, Jan 28, 2020 at 11:35 AM Tom Lane wrote:
>> 3. Some compilers still don't understand that elog(ERROR) doesn't
>> return, so you need a dummy return. Perhaps pg_unreachable()
>> would do as well, but project style has been the dummy return for
>> a long time ... and
On Tue, Jan 28, 2020 at 11:35 AM Tom Lane wrote:
> 3. Some compilers still don't understand that elog(ERROR) doesn't
> return, so you need a dummy return. Perhaps pg_unreachable()
> would do as well, but project style has been the dummy return for
> a long time ... and I'm not entirely convinced
On Tue, Jan 28, 2020 at 5:26 PM Tom Lane wrote:
>
> Robert Haas writes:
> > On Tue, Jan 28, 2020 at 10:19 AM Julien Rouhaud wrote:
> >> FTR this has unfortunately the same result on Thomas' automatic patch
> >> tester, e.g.
> >> https://travis-ci.org/postgresql-cfbot/postgresql/builds/642634195
Robert Haas writes:
> On Tue, Jan 28, 2020 at 10:30 AM Mahendra Singh Thalor
> wrote:
>> Tom Lane already fixed this and committed
>> yesterday(4589c6a2a30faba53d0655a8e).
> Oops. OK, thanks.
Yeah, there were multiple issues here:
1. If a switch is expected to cover all values of an enum type
On Mon, Jan 27, 2020 at 3:05 PM Mark Dilger
wrote:
> Since you’ve committed your 0004 and 0005 patches, this v6 patch set is now
> based on a fresh copy of master.
I think the first question for 0005 is whether want this at all.
Initially, you proposed NOT committing it, but then Andrew reviewed
Robert Haas writes:
> On Tue, Jan 28, 2020 at 10:19 AM Julien Rouhaud wrote:
>> FTR this has unfortunately the same result on Thomas' automatic patch
>> tester, e.g.
>> https://travis-ci.org/postgresql-cfbot/postgresql/builds/642634195#L1968
> That's unfortunate ... but presumably Tom's changes
On Tue, Jan 28, 2020 at 10:19 AM Julien Rouhaud wrote:
> FTR this has unfortunately the same result on Thomas' automatic patch
> tester, e.g.
> https://travis-ci.org/postgresql-cfbot/postgresql/builds/642634195#L1968
That's unfortunate ... but presumably Tom's changes took care of this?
--
Rob
On Tue, Jan 28, 2020 at 10:30 AM Mahendra Singh Thalor
wrote:
> Tom Lane already fixed this and committed
> yesterday(4589c6a2a30faba53d0655a8e).
Oops. OK, thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, 28 Jan 2020 at 20:36, Robert Haas wrote:
>
> On Mon, Jan 27, 2020 at 2:02 PM Mahendra Singh Thalor
> wrote:
> > I can see one warning on HEAD.
> >
> > jsonapi.c: In function ‘json_errdetail’:
> > jsonapi.c:1068:1: warning: control reaches end of non-void function
> > [-Wreturn-type]
> >
On Tue, Jan 28, 2020 at 4:06 PM Robert Haas wrote:
>
> On Mon, Jan 27, 2020 at 2:02 PM Mahendra Singh Thalor
> wrote:
> > I can see one warning on HEAD.
> >
> > jsonapi.c: In function ‘json_errdetail’:
> > jsonapi.c:1068:1: warning: control reaches end of non-void function
> > [-Wreturn-type]
> >
On Mon, Jan 27, 2020 at 3:05 PM Mark Dilger
wrote:
> I’m attaching a new patch set with these three changes including Mahendra’s
> patch posted elsewhere on this thread.
>
> Since you’ve committed your 0004 and 0005 patches, this v6 patch set is now
> based on a fresh copy of master.
OK, so I t
On Mon, Jan 27, 2020 at 2:02 PM Mahendra Singh Thalor
wrote:
> I can see one warning on HEAD.
>
> jsonapi.c: In function ‘json_errdetail’:
> jsonapi.c:1068:1: warning: control reaches end of non-void function
> [-Wreturn-type]
> }
> ^
>
> Attaching a patch to fix warning.
Hmm, I don't get a war
> On Jan 27, 2020, at 5:30 AM, Robert Haas wrote:
>
> On Sun, Jan 26, 2020 at 9:05 PM Mark Dilger
> wrote:
>> Ok, the tests pass. Here are those two patches again, both regenerated with
>> a fresh invocation of ‘git format-patch’.
>
> Regarding 0006:
>
> +#ifndef FRONTEND
> #include "misca
On Mon, 27 Jan 2020 at 19:00, Robert Haas wrote:
>
> On Sun, Jan 26, 2020 at 9:05 PM Mark Dilger
> wrote:
> > Ok, the tests pass. Here are those two patches again, both regenerated
> > with a fresh invocation of ‘git format-patch’.
>
> Regarding 0006:
>
> +#ifndef FRONTEND
> #include "miscadmi
On Sun, Jan 26, 2020 at 9:05 PM Mark Dilger
wrote:
> Ok, the tests pass. Here are those two patches again, both regenerated with
> a fresh invocation of ‘git format-patch’.
Regarding 0006:
+#ifndef FRONTEND
#include "miscadmin.h"
-#include "utils/jsonapi.h"
+#endif
I suggest
#ifdef FRONTEND
> On Jan 26, 2020, at 5:51 PM, Andrew Dunstan
> wrote:
>
>>> 0007 adds testing.
>>>
>>> I would appreciate somebody looking at the portability issues for 0007
>>> on Windows.
>>>
>>
>> We'll need at a minimum something added to src/tools/msvc to build the
>> test program, maybe some other s
> > 0007 adds testing.
> >
> > I would appreciate somebody looking at the portability issues for 0007
> > on Windows.
> >
>
> We'll need at a minimum something added to src/tools/msvc to build the
> test program, maybe some other stuff too. I'll take a look.
Patch complains that the 0007 patch is
> On Jan 26, 2020, at 5:09 PM, Andrew Dunstan
> wrote:
>
> We'll need at a minimum something added to src/tools/msvc to build the
> test program, maybe some other stuff too. I'll take a look.
Thanks, much appreciated.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Po
On Mon, Jan 27, 2020 at 5:54 AM Mark Dilger
wrote:
>
>
>
> > On Jan 22, 2020, at 10:53 AM, Robert Haas wrote:
> >
> > 0004 is a substantially cleaned up version of the patch to make the
> > JSON parser return a result code rather than throwing errors. Names
> > have been fixed, interfaces have be
On Sat, Jan 25, 2020 at 6:20 AM Mark Dilger
wrote:
>
>
>
> > On Jan 24, 2020, at 10:43 AM, Robert Haas wrote:
> >
> > Since 0001-0003 have been reviewed by multiple people and nobody's
> > objected, I have committed those.
>
> I think 0004-0005 have been reviewed and accepted by both me and Andre
> On Jan 22, 2020, at 10:53 AM, Robert Haas wrote:
>
> 0004 is a substantially cleaned up version of the patch to make the
> JSON parser return a result code rather than throwing errors. Names
> have been fixed, interfaces have been tidied up, and the thing is
> better integrated with the surro
> On Jan 24, 2020, at 10:43 AM, Robert Haas wrote:
>
> Since 0001-0003 have been reviewed by multiple people and nobody's
> objected, I have committed those.
I think 0004-0005 have been reviewed and accepted by both me and Andrew, if I
understood him correctly:
> I've reviewed these patches
On 2020-Jan-24, Peter Eisentraut wrote:
> I'm not fond of the base64 idea btw., because it seems to sort of penalize
> using non-ASCII characters by making the result completely not human
> readable. Something along the lines of MIME would be better in that way.
> There are existing solutions to
On Thu, Jan 23, 2020 at 1:05 PM Mark Dilger
wrote:
> Ok, I finished merging with Robert’s patches. The attached follow his
> numbering, with my patches intended to by applied after his.
I think it'd be a good idea to move the pg_wchar.h stuff into a new
thread. This thread is getting a bit comp
On 2020-01-24 18:56, Robert Haas wrote:
On Fri, Jan 24, 2020 at 9:48 AM Tom Lane wrote:
Alvaro Herrera writes:
I prefer the encoding scheme myself. I don't see the point of the
error.
Yeah, if we don't want to skip such files, then storing them using
a base64-encoded name (with a different
> On Jan 24, 2020, at 10:03 AM, Alvaro Herrera wrote:
>
> The other is Mark's point about "expected file pattern", which seems a
> slippery slope to me. If the pattern is /^[a-zA-Z0-9_.]*$/ then I'm
> okay with it (maybe add a few other punctuation chars); as you say no
> sane extension would
On 2020-Jan-24, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2020-Jan-24, Mark Dilger wrote:
> >> I would expect, therefore, that we only back up files which match our
> >> expected file name pattern and ignore (perhaps with a warning)
> >> everything else.
>
> > That risks missing files plac
On Fri, Jan 24, 2020 at 9:48 AM Tom Lane wrote:
> Alvaro Herrera writes:
> > I prefer the encoding scheme myself. I don't see the point of the
> > error.
>
> Yeah, if we don't want to skip such files, then storing them using
> a base64-encoded name (with a different key than regular names)
> see
Alvaro Herrera writes:
> On 2020-Jan-24, Mark Dilger wrote:
>> I would expect, therefore, that we only back up files which match our
>> expected file name pattern and ignore (perhaps with a warning)
>> everything else.
> That risks missing files placed in the datadir by extensions;
I agree that
On 2020-Jan-24, Mark Dilger wrote:
> I would expect, therefore, that we only back up files which match our
> expected file name pattern and ignore (perhaps with a warning)
> everything else.
That risks missing files placed in the datadir by extensions; see
discussion about pg_checksums using a wh
Alvaro Herrera writes:
> I prefer the encoding scheme myself. I don't see the point of the
> error.
Yeah, if we don't want to skip such files, then storing them using
a base64-encoded name (with a different key than regular names)
seems plausible. But I don't really see why we'd go to that much
On 2020-Jan-24, David Steele wrote:
> On 1/24/20 10:00 AM, Alvaro Herrera wrote:
> > Maybe we can get away with *ignoring* such files, perhaps after emitting
> > a warning.
>
> I'd prefer an an error (or base64 encoding) rather than just skipping a
> file. The latter sounds scary.
Well, if the
> On Jan 24, 2020, at 8:36 AM, David Steele wrote:
>
>> I don't entirely follow why we're discussing this at all, if the
>> requirement is backing up a PG data directory. There are not, and
>> are never likely to be, any legitimate files with non-ASCII names
>> in that context. Why can't we
On 1/24/20 10:00 AM, Alvaro Herrera wrote:
On 2020-Jan-24, David Steele wrote:
It might be nice to have a strict mode where non-ASCII/UTF8 characters will
error instead, but that can be added on later.
"your backup failed because you have a file we don't like" is not great
behavior. IIRC we
On 2020-Jan-24, David Steele wrote:
> It might be nice to have a strict mode where non-ASCII/UTF8 characters will
> error instead, but that can be added on later.
"your backup failed because you have a file we don't like" is not great
behavior. IIRC we already fail when a file is owned by root (
On 1/24/20 9:27 AM, Tom Lane wrote:
Peter Eisentraut writes:
On 2020-01-23 18:04, Robert Haas wrote:
Now, you might say "well, why don't we just do an encoding
conversion?", but we can't. When the filesystem tells us what the file
names are, it does not tell us what encoding the person who cre
On 1/23/20 11:05 AM, Robert Haas wrote:
> On Thu, Jan 23, 2020 at 12:49 PM Bruce Momjian wrote:
>> Another idea is to use base64 for all non-ASCII file names, so we don't
>> need to check if the file name is valid UTF8 before outputting --- we
>> just need to check for non-ASCII, which is much ea
Peter Eisentraut writes:
> On 2020-01-23 18:04, Robert Haas wrote:
>> Now, you might say "well, why don't we just do an encoding
>> conversion?", but we can't. When the filesystem tells us what the file
>> names are, it does not tell us what encoding the person who created
>> those files had in mi
On 2020-01-23 18:04, Robert Haas wrote:
Now, you might say "well, why don't we just do an encoding
conversion?", but we can't. When the filesystem tells us what the file
names are, it does not tell us what encoding the person who created
those files had in mind. We don't know that they had*any*
> On Jan 23, 2020, at 4:27 PM, Andrew Dunstan
> wrote:
>
> On Fri, Jan 24, 2020 at 7:35 AM Mark Dilger
> wrote:
>>
>>
>>> On Jan 22, 2020, at 7:00 PM, Mark Dilger
>>> wrote:
>>>
>>> I have this done in my local repo to the point that I can build frontend
>>> tools against the json pars
On Fri, Jan 24, 2020 at 7:35 AM Mark Dilger
wrote:
>
>
> > On Jan 22, 2020, at 7:00 PM, Mark Dilger
> > wrote:
> >
> > I have this done in my local repo to the point that I can build frontend
> > tools against the json parser that is now in src/common and also run all
> > the check-world tests
On 2020-Jan-23, Bruce Momjian wrote:
> Yes, good point. I think my one concern is that someone might specify
> both keys in the JSON, which would be very odd.
Just make that a reason to raise an error. I think it's even possible
to specify that as a JSON Schema constraint, using a "oneOf" predi
On Thu, Jan 23, 2020 at 2:08 PM Daniel Verite wrote:
> It could be CSV, which has this problem already solved,
> is easier to parse than JSON, certainly no less popular,
> and is not bound to a specific encoding.
Sure. I don't think that would look quite as nice visually as what I
proposed when i
Robert Haas wrote:
> With the format I proposed, you only have to worry that the
> file name might contain a tab character, because in that format, tab
> is the delimiter
It could be CSV, which has this problem already solved,
is easier to parse than JSON, certainly no less popular,
and i
On Thu, Jan 23, 2020 at 1:22 PM Bruce Momjian wrote:
> Yes, good point. I think my one concern is that someone might specify
> both keys in the JSON, which would be very odd.
I think that if a tool other than PostgreSQL chooses to generate a
PostreSQL backup manifest, it must take care to do it
On Thu, Jan 23, 2020 at 02:00:23PM -0500, Robert Haas wrote:
> Incidentally, some research seems to suggest that the problem of
> filenames which don't form a valid UTF-8 sequence cannot occur on
> Windows. This blog post may be helpful in understanding the issues:
>
> http://beets.io/blog/paths.h
On Thu, Jan 23, 2020 at 03:20:27PM -0300, Alvaro Herrera wrote:
> On 2020-Jan-23, Bruce Momjian wrote:
>
> > On Thu, Jan 23, 2020 at 01:05:50PM -0500, Robert Haas wrote:
> > > > Another
> > > > problem, though, is how do you _flag_ file names as being
> > > > base64-encoded? Use another JSON fiel
On 2020-Jan-23, Bruce Momjian wrote:
> On Thu, Jan 23, 2020 at 01:05:50PM -0500, Robert Haas wrote:
> > > Another
> > > problem, though, is how do you _flag_ file names as being
> > > base64-encoded? Use another JSON field to specify that?
> >
> > Alvaro's proposed solution in the message to whi
On Thu, Jan 23, 2020 at 01:05:50PM -0500, Robert Haas wrote:
> > Another
> > problem, though, is how do you _flag_ file names as being
> > base64-encoded? Use another JSON field to specify that?
>
> Alvaro's proposed solution in the message to which you replied was to
> call the field either 'pat
On Thu, Jan 23, 2020 at 12:49 PM Bruce Momjian wrote:
> Another idea is to use base64 for all non-ASCII file names, so we don't
> need to check if the file name is valid UTF8 before outputting --- we
> just need to check for non-ASCII, which is much easier.
I think that we have the infrastructure
On Thu, Jan 23, 2020 at 12:24 PM Alvaro Herrera
wrote:
> I do have files with Latin-1-encoded names in my filesystem, even though
> my system is UTF-8, so I understand the problem. I was wondering if it
> would work to encode any non-UTF8-valid name using something like
> base64; the encoded name
On Thu, Jan 23, 2020 at 02:23:14PM -0300, Alvaro Herrera wrote:
> On 2020-Jan-23, Robert Haas wrote:
>
> > No, that's not it. Suppose that Álvaro Herrera has some custom
> > settings he likes to put on all the PostgreSQL clusters that he uses,
> > so he creates a file álvaro.conf and uses an "incl
On 2020-Jan-23, Robert Haas wrote:
> No, that's not it. Suppose that Álvaro Herrera has some custom
> settings he likes to put on all the PostgreSQL clusters that he uses,
> so he creates a file álvaro.conf and uses an "include" directive in
> postgresql.conf to suck in those settings. If he also
On Wed, Jan 22, 2020 at 10:00 PM Mark Dilger
wrote:
> Hopefully, this addresses Robert’s concern upthread about the filesystem name
> not necessarily being in utf8 format, though I might be misunderstanding the
> exact thrust of his concern. I can think of other possible interpretations
> of h
On 2020-Jan-22, Robert Haas wrote:
> On Wed, Jan 22, 2020 at 2:26 PM Alvaro Herrera
> wrote:
> > I'm not sure I see the point of keeping json.h split from jsonapi.h. It
> > seems to me that you could move back all the contents from jsonapi.h
> > into json.h, and everything would work just as we
On Wed, Jan 22, 2020 at 2:26 PM Alvaro Herrera wrote:
> I'm not sure I see the point of keeping json.h split from jsonapi.h. It
> seems to me that you could move back all the contents from jsonapi.h
> into json.h, and everything would work just as well. (Evidently the
> Datum in JsonEncodeDateTi
On 2020-Jan-22, Robert Haas wrote:
> Here is a new version that is, I think, much closer what I would
> consider a final form. 0001 through 0003 are as before, and unless
> somebody says pretty soon that they see a problem with those or want
> more time to review them, I'm going to commit them; Da
On Tue, Jan 21, 2020 at 5:34 PM David Steele wrote:
> Though, throw_a_json_error() is not my favorite name. Perhaps
> json_ereport()?
That name was deliberately chosen to be dumb, with the thought that
readers would understand it was to be replaced at some point before
this was final. It sounds
Hi Robert,
On 1/17/20 2:33 PM, Robert Haas wrote:
> On Fri, Jan 17, 2020 at 12:36 PM David Steele
wrote:
>
>> I used the callbacks because that's the first method I found but it
>> seems like json_lex() might be easier to use in practice.
>
> Ugh, really? That doesn't seem like it would be nic
> On Jan 16, 2020, at 1:24 PM, Tom Lane wrote:
>
>>>
>>> Lastly, it strikes me that maybe pg_wchar.h, or parts of it, should
>>> migrate over to src/include/common. But that'd be far more invasive
>>> to other source files, so I've not touched the issue here.
>
>> I don't have a view on this
On Thu, Jan 16, 2020 at 8:55 PM Andrew Dunstan
wrote:
> I'm probably responsible for a good deal of the mess, so let me say Thankyou.
>
> I'll have a good look at these.
Thanks, appreciated.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Hi Robert,
On 1/16/20 11:51 AM, Robert Haas wrote:
On Thu, Jan 16, 2020 at 1:37 PM David Steele wrote:
So the idea here is that json.c will have the JSON SQL functions,
jsonb.c the JSONB SQL functions, and jsonapi.c the parser, and
jsonfuncs.c the utility functions?
Uh, I think roughly that
Hi Robert,
On 1/16/20 11:51 AM, Robert Haas wrote:
On Thu, Jan 16, 2020 at 1:37 PM David Steele wrote:
The next question in my mind is given the caveat that the error handing
is questionable in the front end, can we at least render/parse valid
JSON with the code?
That's a real good question
On Thu, Jan 16, 2020 at 7:33 AM Robert Haas wrote:
>
>
> 0002 does some basic header cleanup to make it possible to include the
> existing header file jsonapi.h in frontend code. The state of the JSON
> headers today looks generally poor. There seems not to have been much
> attempt to get the pro
Robert Haas writes:
> It's possible that we're chasing a real problem here, and if there's
> something we can agree on and get done I'd rather do that than argue,
> but I am still quite suspicious that there's no actually serious
> technical problem here.
It's entirely possible that you're right.
Robert Haas writes:
> On Thu, Jan 16, 2020 at 3:11 PM Tom Lane wrote:
>> Here's a reviewed version of 0001. You missed fixing the MSVC build,
>> and there were assorted comments and other things referencing wchar.c
>> that needed to be cleaned up.
> Wow, thanks.
Pushed that.
>> Another thing
On Thu, Jan 16, 2020 at 1:58 PM David Steele wrote:
> To do page-level incrementals (which this feature is intended to enable)
> the user will need to be able to associate full and incremental backups
> and the only way I see to do that (currently) is to read the manifests,
> since the prior backu
On Thu, Jan 16, 2020 at 3:11 PM Tom Lane wrote:
> Robert Haas writes:
> > 0001 moves wchar.c from src/backend/utils/mb to src/common. Unless I'm
> > missing something, this seems like an overdue cleanup.
>
> Here's a reviewed version of 0001. You missed fixing the MSVC build,
> and there were as
Robert Haas writes:
> 0001 moves wchar.c from src/backend/utils/mb to src/common. Unless I'm
> missing something, this seems like an overdue cleanup.
Here's a reviewed version of 0001. You missed fixing the MSVC build,
and there were assorted comments and other things referencing wchar.c
that ne
On 1/16/20 12:26 PM, Andres Freund wrote:
Hi,
On 2020-01-16 14:20:28 -0500, Tom Lane wrote:
David Steele writes:
The way we handle this in pgBackRest is to put a TRY ... CATCH block in
main() to log and exit on any uncaught THROW. That seems like a
reasonable way to start here. Without memo
Hi,
On 2020-01-16 14:20:28 -0500, Tom Lane wrote:
> David Steele writes:
> > The way we handle this in pgBackRest is to put a TRY ... CATCH block in
> > main() to log and exit on any uncaught THROW. That seems like a
> > reasonable way to start here. Without memory contexts that almost
> > cert
David Steele writes:
> On 1/15/20 7:39 PM, Robert Haas wrote:
>>> I agree that it's far from obvious that the hacks in the patch are
>>> best; to the contrary, they are hacks. That said, I feel that the
>>> semantics of throwing an error are not very well-defined in a
>>> front-end environment. I
On 1/15/20 7:39 PM, Robert Haas wrote:
> On Wed, Jan 15, 2020 at 6:40 PM Andres Freund wrote:
>> It's not obvious why the better approach here wouldn't be to just have a
>> very simple ereport replacement, that needs to be explicitly included
>> from frontend code. It'd not be meaningfully harder
On 1/15/20 4:40 PM, Andres Freund wrote:
>
> I'm not sure where I come down between using json and a simple ad-hoc
> format, when the dependency for the former is making the existing json
> parser work in the frontend. But if the alternative is to add a second
> json parser, it very clearly shifts
On Thu, Jan 16, 2020 at 1:37 PM David Steele wrote:
> I was starting to wonder if it wouldn't be simpler to go back to the
> Postgres JSON parser and see if we can adapt it. I'm not sure that it
> *is* simpler, but it would almost certainly be more acceptable.
That is my feeling also.
> So the
Hi Robert,
On 1/16/20 11:37 AM, David Steele wrote:
The next question in my mind is given the caveat that the error handing
is questionable in the front end, can we at least render/parse valid
JSON with the code?
Hrm, this bit was from an earlier edit. I meant:
The next question in my min
Hi Robert,
On 1/15/20 2:02 PM, Robert Haas wrote:
> The discussion on the backup manifest thread has gotten bogged down on
> the issue of the format that should be used to store the backup
> manifest file. I want something simple and ad-hoc; David Steele and
> Stephen Frost prefer JSON. That is p
On Wed, Jan 15, 2020 at 09:39:13PM -0500, Robert Haas wrote:
> On Wed, Jan 15, 2020 at 6:40 PM Andres Freund wrote:
>> It's not obvious why the better approach here wouldn't be to just have a
>> very simple ereport replacement, that needs to be explicitly included
>> from frontend code. It'd not b
On Wed, Jan 15, 2020 at 6:40 PM Andres Freund wrote:
> It's not obvious why the better approach here wouldn't be to just have a
> very simple ereport replacement, that needs to be explicitly included
> from frontend code. It'd not be meaningfully harder, imo, and it'd
> require fewer adaptions, an
Hi,
On 2020-01-15 16:02:49 -0500, Robert Haas wrote:
> The discussion on the backup manifest thread has gotten bogged down on
> the issue of the format that should be used to store the backup
> manifest file. I want something simple and ad-hoc; David Steele and
> Stephen Frost prefer JSON. That is
Robert Haas writes:
> ... However, I decided to spend today doing some further
> investigation of an alternative approach, namely making the backend's
> existing JSON parser work in frontend code as well. I did not solve
> all the problems there, but I did come up with some patches which I
> think
The discussion on the backup manifest thread has gotten bogged down on
the issue of the format that should be used to store the backup
manifest file. I want something simple and ad-hoc; David Steele and
Stephen Frost prefer JSON. That is problematic because our JSON parser
does not work in frontend
97 matches
Mail list logo
