Re: proposal: condition blocks in psql

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: condition blocks in psql
Date: 2015-06-28 12:39:49
Message-ID: 558FEB15.9010802@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 06/28/2015 02:21 PM, Pavel Stehule wrote:
>
> 2015-06-28 14:12 GMT+02:00 Tomas Vondra
> <tomas(dot)vondra(at)2ndquadrant(dot)com <mailto:tomas(dot)vondra(at)2ndquadrant(dot)com>>:
>
> This proposal is not against to DO parametrization. It is same like
> conditional block in C (#ifdef). There is similarity with C
> statements - and both has sense.

I'm not sure how this is related to C macros - AFAIK psql has no concept
of preprocessing, so effectively all the the conditional statements are
equal. Also, they work directly with psql variables.

You mentioned several reasons for implementing this feature:

* maintenance of large plpgsql functions

* plpgsql functions create a transaction borders

* impossibility to use psql variables in plpgsql code

I don't really buy the assertion that maintenance will be easier with
large amounts of psql-specific scripting language, compared to plpgsql
or regular scripting languages (bash, python, ...). Or more readable.

I also don't see why the transaction borders should be an issue,
especially considering that the code is most often used to maintenance
tasks.

So the only thing remaining is the impossibility to use psql variables
in plpgsql code. And that's the current DO limitation, so let's fix that.

--
Tomas Vondra http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2015-06-28 12:44:05 Re: Refactoring pgbench.c
Previous Message Tomas Vondra 2015-06-28 12:35:52 Re: proposal: condition blocks in psql