Re: proposal - assign result of query to psql variable

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>, Phil Sorber <phil(at)omniti(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, David Fetter <david(at)fetter(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal - assign result of query to psql variable
Date: 2013-02-01 22:56:05
Message-ID: 25422.1359759365@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-02-01 23:03:46 Re: json api WIP patch
Previous Message Christopher Browne 2013-02-01 22:43:04 Re: autovacuum not prioritising for-wraparound tables