Hello 2013/2/1 Tom Lane <t...@sss.pgh.pa.us>: > Pavel Stehule <pavel.steh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
