Agreed. Although given that you can cast text to unknown, and NULL to
text, it's not intuitively clear why this would have to fail absent
replanning. However, knowing nothing about Postgres internals, I'm happy
to take your word for it! Thanks again.
Ken
On Sun, Nov 17, 2013 at 7:59 PM, Tom La
Ken Tanzer writes:
> But thinking about it some more, the function runs one of 5 possible
> queries. 4 of them select NULL as comment (no cast), while the fifth (and
> the one that caused this error) selects 'a string'.
Ah. Fixing that so all the variants produce the same (explicit) type
should
>
> The type of that comment field hasn't changed
Oh, and I'm going to slight eat my words, or at least elaborate. That
comment field has been in all the views unchanged. Until Tuesday, though,
the field wasn't being used or referenced in the function. So that line
195 is actually new as of Tu
Ken Tanzer writes:
> And if this error was from the Friday schema changes, would it have
> auto-corrected itself so it only happened the one time?
Starting a fresh session would've "auto-corrected" it ...
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-
On Sun, Nov 17, 2013 at 6:20 PM, Tom Lane wrote:
> Ken Tanzer writes:
> > Hi. I got an error message reported to me that I've never seen before,
> and
> > I'm not quite sure what it means or what would cause it.
>
> > ERROR: type of parameter 70 (text) does not match that when preparing
> the
Ken Tanzer writes:
> Hi. I got an error message reported to me that I've never seen before, and
> I'm not quite sure what it means or what would cause it.
> ERROR: type of parameter 70 (text) does not match that when preparing the
> plan (unknown) CONTEXT: PL/pgSQL function
> generate_payments(
Hi. I got an error message reported to me that I've never seen before, and
I'm not quite sure what it means or what would cause it. When I re-run the
query now, it runs without complaint, so the problem seems to have gone
away. Which of course I don't understand either! Would be nice to know
fo
