pl/pgSQL doco patch

Started by Philip Yarraover 20 years ago6 messagesdocs
Jump to latest
#1Philip Yarra
philip@utiba.com

Hi, I supplied a minor doco patch relating to porting pl/SQL to pl/pgSQL:
http://archives.postgresql.org/pgsql-hackers/2005-10/msg01295.php. Also
attached here.

Could someone please review and apply this for me?

Regards, Philip.

--

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

-----------------
Utiba Pty Ltd
This message has been scanned for viruses and
dangerous content by Utiba mail server and is
believed to be clean.

Attachments:

doc-plpgsql-oraport.patchtext/x-diff; charset=us-ascii; name=doc-plpgsql-oraport.patchDownload+7-0
#2Bruce Momjian
bruce@momjian.us
In reply to: Philip Yarra (#1)
Re: pl/pgSQL doco patch

Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

---------------------------------------------------------------------------

Philip Yarra wrote:

Hi, I supplied a minor doco patch relating to porting pl/SQL to pl/pgSQL:
http://archives.postgresql.org/pgsql-hackers/2005-10/msg01295.php. Also
attached here.

Could someone please review and apply this for me?

Regards, Philip.

--

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

-----------------
Utiba Pty Ltd
This message has been scanned for viruses and
dangerous content by Utiba mail server and is
believed to be clean.

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#3Andrew Dunstan
andrew@dunslane.net
In reply to: Philip Yarra (#1)
Re: [PATCHES] pl/pgSQL doco patch

I am wondering we should make this warning more prominent - it would be
easily missed buried on the Oracle porting section, and I have seen
people caught by it lots of times.

cheers

andrew

Philip Yarra wrote:

Show quoted text

Hi, I supplied a minor doco patch relating to porting pl/SQL to pl/pgSQL:
http://archives.postgresql.org/pgsql-hackers/2005-10/msg01295.php. Also
attached here.

Could someone please review and apply this for me?

Regards, Philip.

------------------------------------------------------------------------

Index: doc/src/sgml/plpgsql.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/plpgsql.sgml,v
retrieving revision 1.79
diff -c -r1.79 plpgsql.sgml
*** doc/src/sgml/plpgsql.sgml	21 Oct 2005 05:11:23 -0000	1.79
--- doc/src/sgml/plpgsql.sgml	28 Oct 2005 05:20:54 -0000
***************
*** 3132,3137 ****
--- 3132,3144 ----
state in temporary tables, instead.
</para>
</listitem>
+      <listitem>
+       <para>
+        You cannot use parameter names that are the same as columns 
+        that are referenced in the function. Oracle does allow you to do this
+        if you qualify the parameter name as function_name.paramater_name
+       </para>
+      </listitem>
</itemizedlist>
</para>
#4Philip Yarra
philip@utiba.com
In reply to: Andrew Dunstan (#3)
Re: [PATCHES] pl/pgSQL doco patch

On Thu, 17 Nov 2005 01:40 am, Andrew Dunstan wrote:

I am wondering we should make this warning more prominent - it would be
easily missed buried on the Oracle porting section, and I have seen
people caught by it lots of times.

I added it to the Oracle section because I found this syntax while porting an
Oracle stored proc to a pl/pgSQL function, and assumed it was an Oracle-ism.

Do other RDBMSs also allow you to qualify function_name.param_name to
distinguish a param from a column of the same name? If so, sure, I'll put it
somewhere more general (suggestions?), and Tom, I think that would lend
weight to allowing PostgreSQL to do it too (not because it's The Right Thing,
but for interoperability and ease of porting). Thoughts?

Regards, Philip.

--

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

-----------------
Utiba Pty Ltd
This message has been scanned for viruses and
dangerous content by Utiba mail server and is
believed to be clean.

#5Bruce Momjian
bruce@momjian.us
In reply to: Philip Yarra (#1)
Re: pl/pgSQL doco patch

Add documentation about the inability of plpsql to use parameter names
that are the same as column names used in the function. I moved the
item up on the list of porting issues.

Patch applied to CVS HEAD and 8.1.X. Thanks.

---------------------------------------------------------------------------

Philip Yarra wrote:

Hi, I supplied a minor doco patch relating to porting pl/SQL to pl/pgSQL:
http://archives.postgresql.org/pgsql-hackers/2005-10/msg01295.php. Also
attached here.

Could someone please review and apply this for me?

Regards, Philip.

--

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

-----------------
Utiba Pty Ltd
This message has been scanned for viruses and
dangerous content by Utiba mail server and is
believed to be clean.

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#6Bruce Momjian
bruce@momjian.us
In reply to: Philip Yarra (#4)
Re: [PATCHES] pl/pgSQL doco patch

I think the Oracle porting section is the correct place for this item.
Thanks for the patch.

---------------------------------------------------------------------------

Philip Yarra wrote:

On Thu, 17 Nov 2005 01:40 am, Andrew Dunstan wrote:

I am wondering we should make this warning more prominent - it would be
easily missed buried on the Oracle porting section, and I have seen
people caught by it lots of times.

I added it to the Oracle section because I found this syntax while porting an
Oracle stored proc to a pl/pgSQL function, and assumed it was an Oracle-ism.

Do other RDBMSs also allow you to qualify function_name.param_name to
distinguish a param from a column of the same name? If so, sure, I'll put it
somewhere more general (suggestions?), and Tom, I think that would lend
weight to allowing PostgreSQL to do it too (not because it's The Right Thing,
but for interoperability and ease of porting). Thoughts?

Regards, Philip.

--

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

-----------------
Utiba Pty Ltd
This message has been scanned for viruses and
dangerous content by Utiba mail server and is
believed to be clean.

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073