Hello
2013/2/1 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> here is patch related to your proposal
>
> I looked at this a bit. It's getting there, though I still don't trust
> the places where you've chosen to clear the prefix setting. (Looking at
> it, I'm now not sure that I trust the implementation of \g either.)
>
> However, what I wanted to ask about was this:
>
>> + if (PQgetisnull(result, 0, i))
>> + value = pset.popt.nullPrint ? pset.popt.nullPrint : "";
>> + else
>> + value = PQgetvalue(result, 0, i);
>
> What's the argument for using nullPrint here? ISTM that's effectively a
> form of escaping, and I'd not expect that to get applied to values going
> into variables, any more than any other formatting we do when printing
> results.
>
> Admittedly, if we just take the PQgetvalue result blindly, there'll
> be no way to tell the difference between empty-string and NULL results.
> But I'm not convinced that this approach is better. It would certainly
> need more than no documentation.
>
I have not strong opinion about storing NULL value - and nullPrint is
a best from simple variants -
possible variants
a) don't store NULL values - and remove existing variable when NULL
be assigned - it is probably best, but should be confusing for users
b) implement flag IS NULL - for variables
c) use nullPrint
d) use empty String
@d is subset of @c, and I think so it put some better possibilities
with only two lines more
@a is probably best - but significant change - not hard to implement it
SELECT NULL AS x \g pref_
SELECT :'pref_' IS NULL;
is can be nice
but it should be premature optimization too - nullPrint is enough for
typical use cases
Regards
Pavel
Regards
Pavel
> regards, tom lane
