Alexander Lakhin writes:
> Please look at the function _readA_Const() (introduced in a6bc33019), which
> fails on current master under valgrind:
> ...
> Here _readA_Const() performs:
> union ValUnion *tmp = nodeRead(NULL, 0);
> memcpy(_node->val, tmp,
Hello,
26.09.2022 17:46, Peter Eisentraut wrote:
On 22.09.22 23:21, Tom Lane wrote:
Anyway, this is a bit far afield from the stated topic of this
thread. I think we should commit something approximately like
what I posted and then start a new thread specifically about
what we'd like to do
On 22.09.22 23:21, Tom Lane wrote:
Anyway, this is a bit far afield from the stated topic of this
thread. I think we should commit something approximately like
what I posted and then start a new thread specifically about
what we'd like to do about utility commands in new-style SQL
functions.
I wrote:
> I left off the last one because it fails check-world: we now
> get through the core regression tests okay, but then the pg_dump
> tests fail on the new SQL function. To fix that, we would have
> to extend ruleutils.c's get_utility_query_def() to be able to
> fully reconstruct any legal
Andres Freund writes:
> On 2022-09-22 12:48:47 -0400, Tom Lane wrote:
>> After staring at the code a bit, I think we don't need to touch
>> pg_strtok() per se. I propose that this can be resolved with changes
>> at the next higher level. Let's make outToken print NULL as <> as
>> it always has,
On 2022-09-22 12:48:47 -0400, Tom Lane wrote:
> I wrote:
> > I think this is the issue Peter mentioned about needing to distinguish
> > between empty strings and NULL strings. We're going to need to rethink
> > the behavior of pg_strtok() a bit to fix that.
>
> After staring at the code a bit, I
I wrote:
> I think this is the issue Peter mentioned about needing to distinguish
> between empty strings and NULL strings. We're going to need to rethink
> the behavior of pg_strtok() a bit to fix that.
After staring at the code a bit, I think we don't need to touch
pg_strtok() per se. I
Andres Freund writes:
> On 2022-08-24 17:25:31 +0200, Peter Eisentraut wrote:
>> Here are patches for that.
> These patches have been failing since they were posted, afaict:
> https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/39/3848
> I assume that's known?
I think this is
Hi,
On 2022-08-24 17:25:31 +0200, Peter Eisentraut wrote:
> Here are patches for that.
These patches have been failing since they were posted, afaict:
https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/39/3848
I assume that's known? Most of the failures seem to be things like
On 13.07.22 00:38, Tom Lane wrote:
Peter Eisentraut writes:
This is also needed to be able to store utility statements in (unquoted)
SQL function bodies. I have some in-progress code for that that I need
to dust off. IIRC, there are still some nontrivial issues to work
through on the reading
Peter Eisentraut writes:
> This is also needed to be able to store utility statements in (unquoted)
> SQL function bodies. I have some in-progress code for that that I need
> to dust off. IIRC, there are still some nontrivial issues to work
> through on the reading side. I don't have a
I wrote:
> There might be enough node types that are raw-parse-tree-only,
> but not involved in utility statements, to make it worth
> continuing to suppress readfuncs support for them. But I kinda
> doubt it. I'll try to get some numbers later today.
Granting that we want write/read support
Peter Eisentraut writes:
> On 10.07.22 00:20, Tom Lane wrote:
>> We've long avoided building I/O support for utility-statement node
>> types, mainly because it didn't seem worth the trouble to write and
>> maintain such code by hand.
k
> This is also needed to be able to store utility statements
On 10.07.22 00:20, Tom Lane wrote:
We've long avoided building I/O support for utility-statement node
types, mainly because it didn't seem worth the trouble to write and
maintain such code by hand. Now that the automatic node-support-code
generation patch is in, that argument is gone, and it's
Hi,
Now we are ready to have debug_print_raw_parse (or something like
that)? Pgpool-II has been importing and using PostgreSQL's raw
parser for years. I think it would be great for PostgreSQL and
Pgpool-II developers to have such a feature.
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Andres Freund writes:
> On 2022-07-10 19:12:52 -0400, Tom Lane wrote:
>> They're not so much "cold" as "dead", so I don't see the point
>> of having them at all. If we ever start allowing utility commands
>> (besides NOTIFY) in stored rules, we'd need readfuncs support then
>> ... but at least
Hi,
On 2022-07-10 19:12:52 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-07-09 18:20:26 -0400, Tom Lane wrote:
> >> For my taste, the circa 20K growth in outfuncs.o is an okay
> >> price for being able to inspect utility statements more easily.
> >> However, I'm less thrilled with
Andres Freund writes:
> On 2022-07-09 18:20:26 -0400, Tom Lane wrote:
>> For my taste, the circa 20K growth in outfuncs.o is an okay
>> price for being able to inspect utility statements more easily.
>> However, I'm less thrilled with the 30K growth in readfuncs.o,
>> because I can't see that
Hi,
On 2022-07-09 18:20:26 -0400, Tom Lane wrote:
> We've long avoided building I/O support for utility-statement node
> types, mainly because it didn't seem worth the trouble to write and
> maintain such code by hand. Now that the automatic node-support-code
> generation patch is in, that
We've long avoided building I/O support for utility-statement node
types, mainly because it didn't seem worth the trouble to write and
maintain such code by hand. Now that the automatic node-support-code
generation patch is in, that argument is gone, and it's just a matter
of whether the benefits
20 matches
Mail list logo
