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
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-ba
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
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 b
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 declaration
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 en
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 hav
AK 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
> one less rul
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 le
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 wou
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. Th
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
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 seems consiste
On Fri, Nov 22, 2013 at 4:34 PM, Mike Blackwell 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 several more
> procedural
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 s
16 matches
Mail list logo