> FWIW, I share Peter's poor opinion of this syntax. I can see the
> appeal of not having to write an explicit check of the rowcount
> afterwards, but that appeal is greatly weakened by the strange syntax.
> (IOW, if you were counting me as a + vote, that was only a vote for
> the concept --- on
"Marko Tiikkaja" writes:
> If I'm counting correctly, we have four votes for this patch and two votes
> against it.
> Any other opinions?
FWIW, I share Peter's poor opinion of this syntax. I can see the
appeal of not having to write an explicit check of the rowcount
afterwards, but that appea
Hi,
If I'm counting correctly, we have four votes for this patch and two votes
against it.
Any other opinions?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hacke
On Fri, 01 Feb 2013 18:11:13 +0100, Peter Eisentraut
wrote:
On 1/26/13 11:28 AM, Marko Tiikkaja wrote:
Here's the second version of the patch, addressing the syntax issues.
I think the new syntax is horribly ugly. The actual command name should
always come first, not options. What will hap
On 1/26/13 11:28 AM, Marko Tiikkaja wrote:
> On Fri, 21 Dec 2012 16:14:19 +0100, I wrote:
>> I wrote a patch
>> which allows you to add STRICT into PERFORM and INSERT/UPDATE/DELETE
>> without specifying an INTO clause.
>
> Here's the second version of the patch, addressing the syntax issues.
I th
On Fri, 21 Dec 2012 16:14:19 +0100, I wrote:
I wrote a patch
which allows you to add STRICT into PERFORM and INSERT/UPDATE/DELETE
without specifying an INTO clause.
Here's the second version of the patch, addressing the syntax issues. I
also couldn't make the grammar work with PERFORM STRICT
On Fri, Dec 21, 2012 at 4:53 PM, Tom Lane wrote:
> That was my first reaction too, but Marko's followon examples seem to
> make a reasonable case for it. There are many situations where you
> expect an UPDATE or DELETE to hit exactly one row. Often, programmers
> won't bother to add code to chec
2012/12/21 Tom Lane :
> Christopher Browne writes:
>> This is adding specific syntax for what seems like an unusual case to me,
>> which seems like an unworthwhile complication.
>
> That was my first reaction too, but Marko's followon examples seem to
> make a reasonable case for it. There are ma
Christopher Browne writes:
> This is adding specific syntax for what seems like an unusual case to me,
> which seems like an unworthwhile complication.
That was my first reaction too, but Marko's followon examples seem to
make a reasonable case for it. There are many situations where you
expect
On Fri, Dec 21, 2012 at 4:22 PM, Tom Lane wrote:
> What about before it, ie
>
> STRICT UPDATE ...
+1 from me too.
This feature would be awesome.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpre
On 12/21/12 5:22 PM, Tom Lane wrote:
Marko Tiikkaja writes:
Another idea would be to force the STRICT to be immediately after
INSERT, UPDATE or DELETE.
What about before it, ie
STRICT UPDATE ...
This should dodge the problem of possible conflict with table names,
and it seems to me
On 12/21/12 5:09 PM, Christopher Browne wrote:
I could use GET DIAGNOSTICS to determine if nothing got altered, and
it seems likely to me that expressly doing this via IF/ELSE/END IF would
be easier to read in function code than a somewhat magic STRICT
side-effect.
STRICT is used in INTO, so PL
2012/12/21 Tom Lane :
> Marko Tiikkaja writes:
>> Another idea would be to force the STRICT to be immediately after
>> INSERT, UPDATE or DELETE.
>
> What about before it, ie
>
> STRICT UPDATE ...
>
> This should dodge the problem of possible conflict with table names,
> and it seems to me
Marko Tiikkaja writes:
> Another idea would be to force the STRICT to be immediately after
> INSERT, UPDATE or DELETE.
What about before it, ie
STRICT UPDATE ...
This should dodge the problem of possible conflict with table names,
and it seems to me to read more naturally too.
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Marko Tiikkaja
> Sent: Friday, December 21, 2012 10:53 AM
> To: Tom Lane
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] PL/PgSQL STRICT
On Fri, Dec 21, 2012 at 10:39 AM, Tom Lane wrote:
>
> Marko Tiikkaja writes:
> > Courtesy of me, Christmas comes a bit early this year. I wrote a patch
> > which allows you to add STRICT into PERFORM and INSERT/UPDATE/DELETE
> > without specifying an INTO clause.
>
> What is the use-case for thi
2012/12/21 Marko Tiikkaja :
> On 12/21/12 4:49 PM, I wrote:
>>
>> On 12/21/12 4:39 PM, Tom Lane wrote:
>>>
>>> What is the use-case for this?
>>
>>
>> Currently, the way to do this would be something like:
>
>
> I realize I didn't really answer the question.
>
> The use case is when you're UPDATEin
On 12/21/12 4:49 PM, I wrote:
Won't this result in the word STRICT
becoming effectively reserved in contexts where it currently is not?
It will, which probably is not ideal if it can be avoided. I also
considered syntax like INTO STRICT NULL, but that felt a bit ugly. It
would be great if s
On 12/21/12 4:49 PM, I wrote:
On 12/21/12 4:39 PM, Tom Lane wrote:
What is the use-case for this?
Currently, the way to do this would be something like:
I realize I didn't really answer the question.
The use case is when you're UPDATEing or DELETEing a row and you want to
quickly assert th
On 12/21/12 4:39 PM, Tom Lane wrote:
What is the use-case for this?
Currently, the way to do this would be something like:
DECLARE
_ok bool;
BEGIN
UPDATE foo .. RETURNING TRUE INTO STRICT _ok;
We have a lot of code like this, and I bet others do as well.
Won't this result in the word STRI
Marko Tiikkaja writes:
> Courtesy of me, Christmas comes a bit early this year. I wrote a patch
> which allows you to add STRICT into PERFORM and INSERT/UPDATE/DELETE
> without specifying an INTO clause.
What is the use-case for this? Won't this result in the word STRICT
becoming effectively
Hi,
Courtesy of me, Christmas comes a bit early this year. I wrote a patch
which allows you to add STRICT into PERFORM and INSERT/UPDATE/DELETE
without specifying an INTO clause. Observe:
=# create table foo(a int);
CREATE TABLE
=# create function foof() returns void as $$ begin update stri
22 matches
Mail list logo
