Heikki Linnakangas <hlinn...@iki.fi> writes:
> I'm actually not even sure if it's intentional to throw the error even
> with "char[1]". It makes sense to give an error on "char", but who says
> that "char[1]" isn't a valid string?
I agree that that behavior looks more like an implementation artifact
than anything else.
> If we can easily distinguish between "char" and any array of char here,
> might be best to accept the all arrays regardless of the length.
The data structure is so poorly documented that I'm hesitant to try
to do that. It might work to test for type == ECPGt_array, but then
why is the immediately following code explicitly allowing for both
that case and not-array? I'm also fairly unsure how ECPGt_string
fits in here. If this were an important point then it might be
worth trying to reverse-engineer all this, but right now I have
better things to do.
regards, tom lane
