How to test my ad-hoc SQL with parameters in Postgres query window

Question

In Microsoft SQL Server, to test something like this in the query window:

select * from Users where LastName = @lastname

I can add this bef

Answer 1

I config postgres to log all the commands, and copy the command from the log file, so all the parameters are already replaced with the value, and test the command in the query window.

May not be the best approach, but it is easy and works for me

Answer 2

Perhaps using the DO instruction to simulate a function. In that way you can declare variables and use them to execute your query!

http://www.postgresql.org/docs/9.4/static/sql-do.html

Answer 3

Various options.

Provide parameters in a CTE to have "variables" in pure SQL:

WITH var(lastname) AS (SELECT 'Troy'::varchar(16))
SELECT *
FROM   users, var v
WHERE  lastname = v.lastname;

This works for any query.
Since the CTE var holds a single row it is safe to append it with a CROSS JOIN at the end of the FROM clause - actually the short form with appending it after a comma may be best because explicit join syntax binds before commas. The additional table alias v is optional to further shorten the syntax.

OR cheaper without CTE. BTW, why varchar(16)? Just use text:

SELECT *
FROM   users
JOIN  (SELECT 'Troy'::text) var(lastname) USING (lastname);

Or use a temporary table to play a similar role for all queries within the same session. Temp tables die with the end of the session.

CREATE TEMP TABLE var AS
SELECT text 'Troy' AS lastname;

ANALYZE var;  -- temp tables are not covered by autovacuum

SELECT * FROM users JOIN var USING (lastname);

• About temporary tables and autovacuum

Or you can use DO statements like @Houari supplied or like demonstrated here:

• PostgreSQL loops outside functions. Is that possible?

Note that you cannot return values from DO statements. (You can use RAISE ... though.) And you cannot use SELECT without target in plpgsql - the default procedural language in a DO statement. Replace SELECT with PERFORM to throw away results.

Or you can use customized options, which you can set in postgresql.conf to be visible globally.

Or set in your session to be visible for the duration of the session and only in the same session:

SET my.lastname = 'Troy';

The variable name must include a dot. You are limited to text as data type this way, but any data type can be represented as text ...

You can use current_setting('my.lastname') as value expression. Cast if you need. For example: current_setting('my.json_var')::json ...

Or use SET LOCAL for the effect to only last for the current transaction.

Related answer by @Craig:

• Passing user id to PostgreSQL triggers

Or you can use tiny IMMUTABLE functions as global persisted variables that only privileged users can manipulate:

• Is there a way to define a named constant in a PostgreSQL query?

This related answer also has a similar list of options.

psql

Has \set or \gset meta-commands and provides variable substitution in the client.

pgAdmin

The pgAdmin query window offers the extension pgScript.