From: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Possible fault with resolve column name (plpgsql) |
Date: | 2021-09-16 22:58:25 |
Message-ID: | CAEudQAp9umFdAvRF2YFs728m=dhytQmxHzfCYm1kx=w3+8wQyg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Em qui., 16 de set. de 2021 às 17:05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> escreveu:
> Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> writes:
> > Found by llvm scan build.
> > Argument with 'nonnull' attribute passed null pl/plpgsql/src/pl_comp.c
> > resolve_column_ref
>
> This is somewhere between pointless and counterproductive.
Not if you've ever used llvm scan, but it's pretty accurate in identifying
what the condition might occur.
> colname won't
> be used unless the switch has set nnames_field (and the identified number
> of names matches that).
13
← <#Path12>
Assuming field 'type' is equal to T_String
→ <#Path14>
22
← <#Path21>
Assuming 'nnames' is equal to 'nnames_field'
→ <#Path23>
If that logic somehow went wrong, I'd *want*
> the later strcmp to dump core, not possibly give a false match.
>
In this case, strcmp will fail silently, without any coredump.
If we have a record, and the field is T_String, always have a true match?
regards,
Ranier Vilela
From | Date | Subject | |
---|---|---|---|
Next Message | Bossart, Nathan | 2021-09-16 23:26:55 | Re: .ready and .done files considered harmful |
Previous Message | Sehrope Sarkuni | 2021-09-16 21:27:20 | Re: Add jsonlog log_destination for JSON server logs |