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
This is my first patch, so sorry if I miss something.
If I have a function which returns lots of columns and any of these columns
returns a wrong type it's not easy to see which one is that column because
it points me only to its position, not its name. So, this patch only adds
that column name, j
13 matches
Mail list logo
