On 11/25/2013 03:36 PM, David Johnston wrote:
Doh!
IF / THEN / ELSE / ENDIF (concept, not syntax)
That also does help to reinforce the point being made here...
David J.
What point?
PL/pgSQL has been in use for 14 years. During that entire time, it has
always used a block-based
Josh Berkus wrote
On 11/25/2013 03:36 PM, David Johnston wrote:
Doh!
IF / THEN / ELSE / ENDIF (concept, not syntax)
That also does help to reinforce the point being made here...
David J.
What point?
That the status-quo should be maintained.
David J.
--
View this message in
Kevin,
I do see your logic now, but this thing is a common mistake - it means that
this seems counter-intuitive to some people. What would happen if we applied
Occam's razor and just removed this rule?
All existing code would continue to work as is, and we would have one less
rule to memorize.
On 11/25/2013 03:42 PM, AK wrote:
Kevin,
I do see your logic now, but this thing is a common mistake - it means that
this seems counter-intuitive to some people. What would happen if we applied
Occam's razor and just removed this rule?
All existing code would continue to work as is, and we
AK wrote
Kevin,
I do see your logic now, but this thing is a common mistake - it means
that this seems counter-intuitive to some people. What would happen if we
applied Occam's razor and just removed this rule?
All existing code would continue to work as is, and we would have one less
AK alk...@gmail.com wrote:
I do see your logic now, but this thing is a common mistake - it
means that this seems counter-intuitive to some people. What
would happen if we applied Occam's razor and just removed this
rule?
All existing code would continue to work as is, and we would have
On 26/11/13 09:42, AK wrote:
Kevin,
I do see your logic now, but this thing is a common mistake - it means that
this seems counter-intuitive to some people. What would happen if we applied
Occam's razor and just removed this rule?
All existing code would continue to work as is, and we would
Mark Kirkwood-2 wrote
Postgres supports many procedural languages (e.g plperl, plpython) and all
these have different
grammar rules from SQL - and from each other. We can't (and shouldn't)
try altering them to be similar to SQL - it would defeat the purpose of
providing a procedural
On 11/25/2013 06:13 PM, David Johnston wrote:
A side observation: why does DECLARE not require a block-end keyword but
instead BEGIN acts as effectively both start and end? BEGIN, IF, FOR,
etc... all come in pairs but DECLARE does not.
A complete block is:
[ DECLARE declarations ]
Andrew Dunstan wrote
On 11/25/2013 06:13 PM, David Johnston wrote:
A side observation: why does DECLARE not require a block-end keyword
but
instead BEGIN acts as effectively both start and end? BEGIN, IF, FOR,
etc... all come in pairs but DECLARE does not.
A complete block is:
[
On 26/11/13 12:13, David Johnston wrote:
Mark Kirkwood-2 wrote
Postgres supports many procedural languages (e.g plperl, plpython) and all
So in the case of plpgsql - it needs to follow the Ada grammar,
otherwise it would be useless.
I do not follow the useless conclusion - what, present day,
I am reading the following in the documentation: Tip: A common mistake is to
write a semicolon immediately after BEGIN. This is incorrect and will result
in a syntax error.
So, common mistake means semicolons after BEGIN seem consistent to many
people - it seems consistent to me as well. If
I believe the section you are reading refers to the BEGIN keyword in the
procedural language plpgsql, not the SQL 'BEGIN' command. The issue stems
from confusing two distinct languages both of which, along with several
more procedural languages, are documented in the same manual.
On 11/22/2013 02:24 PM, AK wrote:
I am reading the following in the documentation: Tip: A common mistake is to
write a semicolon immediately after BEGIN. This is incorrect and will result
in a syntax error.
So, common mistake means semicolons after BEGIN seem consistent to many
people - it
On Fri, Nov 22, 2013 at 4:34 PM, Mike Blackwell mike.blackw...@rrd.com wrote:
I believe the section you are reading refers to the BEGIN keyword in the
procedural language plpgsql, not the SQL 'BEGIN' command. The issue stems
from confusing two distinct languages both of which, along with
AK alk...@gmail.com wrote:
I am reading the following in the documentation: Tip: A common
mistake is to write a semicolon immediately after BEGIN. This is
incorrect and will result in a syntax error.
So, common mistake means semicolons after BEGIN seem consistent
to many people - it seems
On 11/22/2013 05:24 PM, AK wrote:
I am reading the following in the documentation: Tip: A common mistake is to
write a semicolon immediately after BEGIN. This is incorrect and will result
in a syntax error.
So, common mistake means semicolons after BEGIN seem consistent to many
people - it
17 matches
Mail list logo
