Re: proposal: plpgsql - Assert statement - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: proposal: plpgsql - Assert statement
Date
Msg-id 546BA3AD.4030305@BlueTreble.com
Whole thread Raw
In response to Re: proposal: plpgsql - Assert statement  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: proposal: plpgsql - Assert statement  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On 11/18/14, 9:31 AM, Andrew Dunstan wrote:
>
> Frankly, I find this whole proposal, and all the suggested alternatives, somewhat ill-conceived. PLPGSQL is a wordy
language.If you want something more terse, use something else. Adding these sorts of syntactic sugar warts onto the
languagedoesn't seem like a terribly good way to proceed.
 

Such as?

The enormous advantage of plpgsql is how easy it is to run SQL. Every other PL I've looked at makes that WAY harder.
Andthat's assuming you're in an environment where you can install another PL.
 

And honestly, I've never really found plpgsql to be terribly wordy except in a few cases ("assert" being one of them).
Mygeneral experience has been that when I'm doing an IF (other than assert), I'm doing multiple things in the IF block,
soit's really not that big a deal.
 

As for why not do this in a separate function; yes, you can do that. But then you've needlessly added to your context
stack,it's going to be a lot slower, and you can only really replace RAISE's functionality if you're in a version that
hasformat().
 

If someone has another brain-flash on how to make this better I'm all ears. But I don't think arguments like "use
anotherPL" or "it's just syntax sugar" improve things for our users.
 
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: BRIN and PageIndexDeleteNoCompact
Next
From: Heikki Linnakangas
Date:
Subject: Re: BRIN and PageIndexDeleteNoCompact