28.10.2024 19:06, Tom Lane wrote:
I've also dumped buf in read_whole_file() and found that in both
PG_BINARY_R and "r" modes the 0d 0a ending is preserved. But it changed
to 0a with the "rt" mode (see [1]), and it makes the test (and the whole
`meson test`) pass for me.
Interesting. I believe w
Alexander Lakhin writes:
> 27.10.2024 20:41, Tom Lane wrote:
>>> In the no-good-deed-goes-unpunished department: buildfarm member
>>> hamerkop doesn't like this patch [1]. The diffs look like
> I've managed to reproduce the issue with the core.autocrlf=true git setting
> (which sets CR+LF line e
Hello Tom,
27.10.2024 20:41, Tom Lane wrote:
I wrote:
In the no-good-deed-goes-unpunished department: buildfarm member
hamerkop doesn't like this patch [1]. The diffs look like
...
So what I'd like to do to fix this is to change
- if ((file = AllocateFile(filename, PG_BINARY_R)) == NULL)
ne 27. 10. 2024 v 18:42 odesílatel Tom Lane napsal:
> I wrote:
> > In the no-good-deed-goes-unpunished department: buildfarm member
> > hamerkop doesn't like this patch [1]. The diffs look like
> > ...
> > So what I'd like to do to fix this is to change
> > - if ((file = AllocateFile(filenam
I wrote:
> In the no-good-deed-goes-unpunished department: buildfarm member
> hamerkop doesn't like this patch [1]. The diffs look like
> ...
> So what I'd like to do to fix this is to change
> - if ((file = AllocateFile(filename, PG_BINARY_R)) == NULL)
> + if ((file = AllocateFile(filenam
In the no-good-deed-goes-unpunished department: buildfarm member
hamerkop doesn't like this patch [1]. The diffs look like
@@ -77,7 +77,7 @@
ERROR: syntax error at or near "FUNCTIN"
LINE 1: CREATE FUNCTIN my_erroneous_func(int) RETURNS int LANGUAGE S...
^
-QUERY: CREATE FUNCTI
út 22. 10. 2024 v 17:37 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > I'll mark this patch as ready for committer.
>
> Pushed then. Thanks for reviewing!
>
Thank you for this patch. It is really practical
Regards
Pavel
>
> regards, tom lane
>
Pavel Stehule writes:
> I'll mark this patch as ready for committer.
Pushed then. Thanks for reviewing!
regards, tom lane
Hi
pá 11. 10. 2024 v 19:39 odesílatel Pavel Stehule
napsal:
>
>
> pá 11. 10. 2024 v 18:08 odesílatel Tom Lane napsal:
>
>> Pavel Stehule writes:
>> > I tested it and it is working nicely. I tested it against Orafce and I
>> > found an interesting point. The body of plpgsql functions is not
>>
jian he writes:
> just found out the"elog(INFO, "should not reached here");" part never reached.
You didn't check any of the cases we were discussing I guess?
(That is, places in gram.y that throw an error without a
parser_errposition call.)
Note that even if we fix all of those and keep them fi
On Tue, Oct 15, 2024 at 12:45 AM Tom Lane wrote:
>
> jian he writes:
> > On Mon, Oct 14, 2024 at 1:13 AM Tom Lane wrote:
> >> Right, but we might not have entered either of those previous
> >> if-blocks.
>
> > in src/backend/parser/gram.y
> > your makeRawStmt changes (v4) seem to guarantee that
jian he writes:
> On Mon, Oct 14, 2024 at 1:13 AM Tom Lane wrote:
>> Right, but we might not have entered either of those previous
>> if-blocks.
> in src/backend/parser/gram.y
> your makeRawStmt changes (v4) seem to guarantee that
> RawStmt->stmt_location >= 0.
Yes, I would expect that any RawS
po 14. 10. 2024 v 5:38 odesílatel jian he
napsal:
> On Mon, Oct 14, 2024 at 1:13 AM Tom Lane wrote:
> >
> > Pavel Stehule writes:
> > > so 12. 10. 2024 v 9:33 odesílatel jian he >
> > > napsal:
> > >> + /*
> > >> + * If we have a location (which, as said above, we really always
> should)
> > >
jian he writes:
> So if we are in script_error_callback
> `intlocation = callback_arg->stmt_location;`
> location >= 0 will be always true?
No, not if the grammar threw an error.
regards, tom lane
On Mon, Oct 14, 2024 at 1:13 AM Tom Lane wrote:
>
> Pavel Stehule writes:
> > so 12. 10. 2024 v 9:33 odesílatel jian he
> > napsal:
> >> + /*
> >> + * If we have a location (which, as said above, we really always should)
> >> + * then report a line number to aid in localizing problems in big scr
Pavel Stehule writes:
> so 12. 10. 2024 v 9:33 odesílatel jian he
> napsal:
>> + /*
>> + * If we have a location (which, as said above, we really always should)
>> + * then report a line number to aid in localizing problems in big scripts.
>> + */
>> + if (location >= 0)
>> so this part will alwa
so 12. 10. 2024 v 9:33 odesílatel jian he
napsal:
> On Wed, Oct 9, 2024 at 4:18 AM Tom Lane wrote:
> >
>
> > In the attached v4
>
>
> in the upper code two branch, both will call CleanQuerytext
> so in script_error_callback
>
> + /*
> + * If we have a location (which, as said above, we really al
On Wed, Oct 9, 2024 at 4:18 AM Tom Lane wrote:
>
> In the attached v4
in the upper code two branch, both will call CleanQuerytext
so in script_error_callback
+ /*
+ * If we have a location (which, as said above, we really always should)
+ * then report a line number to aid in localizing proble
pá 11. 10. 2024 v 18:08 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > I tested it and it is working nicely. I tested it against Orafce and I
> > found an interesting point. The body of plpgsql functions is not checked.
> > Do you know the reason?
>
> In execute_extension_script():
>
>
Pavel Stehule writes:
> I tested it and it is working nicely. I tested it against Orafce and I
> found an interesting point. The body of plpgsql functions is not checked.
> Do you know the reason?
In execute_extension_script():
/*
* Similarly disable check_function_bodies, to ensure th
Hi
út 8. 10. 2024 v 22:18 odesílatel Tom Lane napsal:
> I wrote:
> > ... There's still a question
> > of whether reporting the whole script as the query is OK when
> > we have a syntax error, but I have no good ideas as to how to
> > make that terser.
>
> I had an idea about this: we can use a p
I wrote:
> ... There's still a question
> of whether reporting the whole script as the query is OK when
> we have a syntax error, but I have no good ideas as to how to
> make that terser.
I had an idea about this: we can use a pretty simple heuristic
such as "break at semicolon-newline sequences".
I wrote:
> It looks like if we did want to suppress that, the right fix is to
> make gram.y track statement start locations more honestly, as in
> 0002 attached (0001 is the same as before).
I did a little bit of further work on this:
* I ran some performance checks and convinced myself that inde
Re: Tom Lane
> Perhaps. I spent a little more effort on this and added code to
> report errors that don't come with an error location. On those,
> we don't have any constraints about what to report in the QUERY
> field, so I made it trim the string to just the current query
> within the script, w
Christoph Berg writes:
> Re: Tom Lane
>> (It might be worth some effort to trim away comments appearing
>> just before a command, but I didn't tackle that here.)
> The "error when psql" comments do look confusing, but I guess in other
> places the comment just before the query adds valuable conte
Christoph Berg writes:
> Re: Tom Lane
>> So the first part of that is great, but if your script file is
>> large you probably won't be happy about having the whole thing
>> repeated in the "QUERY" field. So this needs some work on
>> user-friendliness.
> Does this really have to be addressed? It
Re: Tom Lane
> So the first part of that is great, but if your script file is
> large you probably won't be happy about having the whole thing
> repeated in the "QUERY" field. So this needs some work on
> user-friendliness.
Does this really have to be addressed? It would be way better than it
is
27 matches
Mail list logo
