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
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 |