pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Corey Huinker <corey.huinker@gmail.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Daniel Verite <daniel@manitou-mail.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Developers <pgsql-hackers@postgresql.org>
Subject: Re: Variable substitution in psql backtick expansion
Date: Sun, 2 Apr 2017 21:50:59 +0200 (CEST)
Message-ID: <alpine.DEB.2.20.1704022144470.9265@lancre> (raw)
In-Reply-To: <CADkLM=c+hm2rc0tkKgC-ZgrLttHT2KkfppE+BC-=i-xj+7V-TQ@mail.gmail.com>
References: <bc15034d-b421-42ac-89b1-c3485fa1728b@manitou-mail.org>
	<alpine.DEB.2.20.1704020841490.4632@lancre>
	<CAFj8pRDCfLLNfMyNAjDwgHXS7inThdqgCaSbfKpiYXkb6Mvmwg@mail.gmail.com>
	<alpine.DEB.2.20.1704020917220.4632@lancre>
	<CAFj8pRCVFp+68Tt29sZfn9tE28c2D7u_VzTcXrqjyCVBzAzRsA@mail.gmail.com>
	<alpine.DEB.2.20.1704021303300.4632@lancre>
	<CAFj8pRACH1M=egydH4dAAoo9rRVTkuYCaoyZQK2Yf4BTQuRM5w@mail.gmail.com>
	<CADkLM=dzsbgJdP7KAJnbihxU1XFnWZgit9ye5cWnvkjZXyPbGw@mail.gmail.com>
	<alpine.DEB.2.20.1704021805550.4632@lancre>
	<CADkLM=c+hm2rc0tkKgC-ZgrLttHT2KkfppE+BC-=i-xj+7V-TQ@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>


> src/tools/msvc/Solution.pm:s{PG_VERSION_STR "[^"]+"}{__STRINGIFY(x)
> #x\n#define __STRINGIFY2(z) __STRINGIFY(z)\n#define PG_VERSION_STR
> "PostgreSQL $self->{strver}$extraver, compiled by Visual C++ build "
> __STRINGIFY2(_MSC_VER) ", $bits-bit"};

Well, this is the same hack.

> Without digging too deep, it seems like the redefinition wouldn't be
> harmful, but it might make sense to not use the name STRINGIFY() if only to
> avoid confusion with Solution.pm.

It is the usual name for these macro. What would you suggest?

>>  - how desirable/useful is it to have this in 10?
>
> Extensions and extension-ish packages will love the _NUM vars.

Hmmmm. I'm afraid pg extension scripts (for CREATE EXTENSION) are not 
executed through psql, but server side directly, so there is not much 
backslash-command support.

> There's a lesser need for the _NAME vars.

I put them more for error reporting, eg:

   \if :VERSION_NUM < 110000
     \echo :VERSION_NAME is not supported, should be at least 11.0
     \q
   \endif

-- 
Fabien.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



view thread (96+ messages)  latest in thread

Message-ID: <alpine.DEB.2.20.1704022144470.9265@lancre>
Permalink:  ../alpine.DEB.2.20.1704022144470.9265@lancre/
Also on:    postgresql.org/message-id/alpine.DEB.2.20.1704022144470.9265@lancre

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: coelho@cri.ensmp.fr, corey.huinker@gmail.com, pavel.stehule@gmail.com, daniel@manitou-mail.org, tgl@sss.pgh.pa.us
  Subject: Re: Variable substitution in psql backtick expansion
  In-Reply-To: <alpine.DEB.2.20.1704022144470.9265@lancre>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox