From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Marko Tiikkaja <marko(at)joh(dot)to>, Joel Jacobson <joel(at)trustly(dot)com> |
Subject: | Re: merging some features from plpgsql2 project |
Date: | 2017-01-08 02:39:24 |
Message-ID: | f1b3ee01-35e5-1773-962d-5da4782a24c2@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/7/17 2:06 AM, Pavel Stehule wrote:
>
> SELECT t1 := c1, t2 := c2, ...
>
> - it can be PostgreSQL specific syntax - full control over design
> - maximally robust against typo
> - long syntax, but for short syntax can be used SELECT c1,c2,c3, .. INTO
> STRICT recvar
I don't think overloading a SQL command is a good idea. We'd be in
trouble if ANSI ever introduced :=. I think that could also conflict
with existing operators.
> - what should be no_data_found behave?
Considering where we're at today, I don't think there should be a
default behavior; make the user specify somehow whether missing data is
allowed or not.
> I have nothing about a cost of "new syntax" implementation - but for me
> - it looks like good solution for us - it can be win/win solution. It
> breaks nothing - it introduce nice to have typo robust syntax.
Related to that, I suspect we could add better support to existing
commands for at least some of these things. For example, SELECT ... INTO
NOMULTI (instead of STRICT) to indicate that multiple rows are an error
but missing data is OK.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-01-08 02:53:57 | Re: merging some features from plpgsql2 project |
Previous Message | Jim Nasby | 2017-01-08 02:31:33 | Re: merging some features from plpgsql2 project |