>>> \if_ver_eq 9.2
>>
>> What do you thinking about it?
>>
>> Couldn't this kind of thing be done directly with PL/pgSQL?
>
> you can use PL/pgSQL - but there are some limits
>
> * maintenance large plpgsql functions
I agree with large but that would not necessarily mean complex. Also, some
functions could be in SQL, and just the logic with PL/pgSQL.
> * the plpgsql functions or anonymous functions create a transaction borders
> - what should not be wanted
Hmmm... If something fails when installing an extension, a transaction
border is probably a good thing? Also, the interaction of \if with
possible BEGIN/COMMIT can lead to strange states.
> * I cannot to use psql variables simply in plpgsql code (plpgsql has not
> any macro language)
You can call a function with a variable as an argument:
\set foo 1234 SELECT some_function(:foo);
> - so some patterns are implemented in plpgsql less readable
Which pattern?
> for example, if you can create a script that create some plpgsql function
> for specified PostgreSQL version, then using PLpgSQL for this purpose is
> suboptimal due less readability and maintainability
I'm not that sure about the qualitative assessment, "DO" looks pretty neat
to me.
Moreover this is to be balanced with creating a scope/block/nesting system
in psql which is currently alien to it and would bring its own pitfalls:
psql is really intrinsically line/statement oriented, that would not be
the case with what you're proposing as this logic would be deeply changed,
and people would get stuck within a non-closed \if, this would interact
with \i in possibly strange ways, and so on (say you include a file with a
non closed \if, and then everything you type seems to be ignored, or
a BEGIN is done in an if but the COMMIT was in another which was not
activated because the conditions where not consistent...).
Basically, it looks like a potential Pandora box which is best left with
its lid on.
--
Fabien.
