Re: proposal - assign result of query to psql variable

Hello

2013/2/1 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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