On 2025-03-07 04:05 +0100, Tom Lane wrote:
> Erik Wienhold writes:
> > But I don't see the point in keeping variables atttypid and atttypmod
> > around when those values are now available via outatt. Removing these
> > two variables makes the code easier to read IMO. Done so in the
> > attached
jian he writes:
> On Fri, Mar 7, 2025 at 11:05 AM Tom Lane wrote:
>> Do others agree Erik's version improves readability?
> i think so.
Pushed v4, then.
regards, tom lane
jian he writes:
> While looking at it, in build_attrmap_by_position
> I guess errmsg may be better than errmsg_internal
> since there are around 10 related error messages in
> src/pl/plpgsql/src/expected/plpgsql_record.out,
> so it's user visible.
No, you misunderstand how that works:
er
On Fri, Mar 7, 2025 at 11:05 AM Tom Lane wrote:
>
> Erik Wienhold writes:
> > But I don't see the point in keeping variables atttypid and atttypmod
> > around when those values are now available via outatt. Removing these
> > two variables makes the code easier to read IMO. Done so in the
> > a
Erik Wienhold writes:
> On 2025-03-07 04:05 +0100, Tom Lane wrote:
>> I think the idea of the original coding was to keep those values in
>> registers in the inner loop rather than re-fetching them each time.
> Could be. But the main reason was to hold the output column type as the
> inner loop
Erik Wienhold writes:
> But I don't see the point in keeping variables atttypid and atttypmod
> around when those values are now available via outatt. Removing these
> two variables makes the code easier to read IMO. Done so in the
> attached v4.
I think the idea of the original coding was to k
On 2025-03-06 21:56 +0100, Tom Lane wrote:
> jian he writes:
> > if we print out NameStr(att->attname) then error becomes:
> > +DETAIL: Returned type unknown does not match expected type character
> > varying in column "f2" (position 2).
>
> > In this case, printing out {column \"%s\"} is not h
[ sorry about having let this thread fall off my radar ]
jian he writes:
> if we print out NameStr(att->attname) then error becomes:
> +DETAIL: Returned type unknown does not match expected type character
> varying in column "f2" (position 2).
> In this case, printing out {column \"%s\"} is no
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Only tests checked.
I applied patch (no errors) and did build (no errors
On Mon, Apr 1, 2024 at 3:15 AM Tom Lane wrote:
>
>
> > The format "%d-%s" is not ideal. I suggesst "%d (%s)".
>
> I didn't like that either, for two reasons: if we have a column name
> it ought to be the prominent label, but we might not have one if the
> TupleDesc came from some anonymous source
Erik Wienhold writes:
> On 2024-03-31 15:22 +0200, Marcos Pegoraro wrote:
>> This is my first patch, so sorry if I miss something.
> Please make sure that tests are passing by running make check:
check-world, in fact.
> The format "%d-%s" is not ideal. I suggesst "%d (%s)".
I didn't like that
On 2024-03-31 15:22 +0200, Marcos Pegoraro wrote:
> This is my first patch, so sorry if I miss something.
Please make sure that tests are passing by running make check:
https://www.postgresql.org/docs/current/regress-run.html#REGRESS-RUN-TEMP-INST
The patch breaks src/test/regress/sql/plpgsql.sql
12 matches
Mail list logo
