<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Two Quick and Simple Tips That Will Help You Write Better PL/SQL</title>
	<atom:link href="http://awads.net/wp/2008/02/28/two-quick-and-simple-tips-that-will-help-you-write-better-plsql/feed/" rel="self" type="application/rss+xml" />
	<link>http://awads.net/wp/2008/02/28/two-quick-and-simple-tips-that-will-help-you-write-better-plsql/</link>
	<description>News, views, tips and tricks on Oracle and other fun stuff</description>
	<pubDate>Thu, 20 Nov 2008 22:11:03 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: Eddie Awad</title>
		<link>http://awads.net/wp/2008/02/28/two-quick-and-simple-tips-that-will-help-you-write-better-plsql/#comment-52014</link>
		<dc:creator>Eddie Awad</dc:creator>
		<pubDate>Sat, 01 Mar 2008 19:20:04 +0000</pubDate>
		<guid isPermaLink="false">http://awads.net/wp/2008/02/28/two-quick-and-simple-tips-that-will-help-you-write-better-plsql/#comment-52014</guid>
		<description>By the way, as you've noticed from the example code above, I also like to add _in to the end of IN parameter names, _out for OUT parameters and _inout for IN OUT. This makes the named notation even more readable.</description>
		<content:encoded><![CDATA[<p>By the way, as you&#8217;ve noticed from the example code above, I also like to add _in to the end of IN parameter names, _out for OUT parameters and _inout for IN OUT. This makes the named notation even more readable.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paweł Barut</title>
		<link>http://awads.net/wp/2008/02/28/two-quick-and-simple-tips-that-will-help-you-write-better-plsql/#comment-52013</link>
		<dc:creator>Paweł Barut</dc:creator>
		<pubDate>Sat, 01 Mar 2008 10:10:52 +0000</pubDate>
		<guid isPermaLink="false">http://awads.net/wp/2008/02/28/two-quick-and-simple-tips-that-will-help-you-write-better-plsql/#comment-52013</guid>
		<description>Hi,

I fully agree with Chris. I really like name notation and I use it often, but not always.
When I use standard Oracle build in functions or for well established API (mine, 3rd party, or specific to project) with limited number of parameters (usually up to 3 or 4) I rather use positional notation.
And of course within SQL statements, where named parameters are not allowed (hope I will work on 11g soon)

Regards,
Pawel</description>
		<content:encoded><![CDATA[<p>Hi,</p>
<p>I fully agree with Chris. I really like name notation and I use it often, but not always.<br />
When I use standard Oracle build in functions or for well established API (mine, 3rd party, or specific to project) with limited number of parameters (usually up to 3 or 4) I rather use positional notation.<br />
And of course within SQL statements, where named parameters are not allowed (hope I will work on 11g soon)</p>
<p>Regards,<br />
Pawel</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Eddie Awad</title>
		<link>http://awads.net/wp/2008/02/28/two-quick-and-simple-tips-that-will-help-you-write-better-plsql/#comment-52011</link>
		<dc:creator>Eddie Awad</dc:creator>
		<pubDate>Fri, 29 Feb 2008 01:44:50 +0000</pubDate>
		<guid isPermaLink="false">http://awads.net/wp/2008/02/28/two-quick-and-simple-tips-that-will-help-you-write-better-plsql/#comment-52011</guid>
		<description>Valid points Chris, especially on writing meaningful parameter names, not to mention meaningful variables names, procedure names, function names, package names.... 

Maybe I should not have put "in general", "best practice" and "always" in the same sentence :)</description>
		<content:encoded><![CDATA[<p>Valid points Chris, especially on writing meaningful parameter names, not to mention meaningful variables names, procedure names, function names, package names&#8230;. </p>
<p>Maybe I should not have put &#8220;in general&#8221;, &#8220;best practice&#8221; and &#8220;always&#8221; in the same sentence <img src='http://awads.net/wp/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Muir</title>
		<link>http://awads.net/wp/2008/02/28/two-quick-and-simple-tips-that-will-help-you-write-better-plsql/#comment-52010</link>
		<dc:creator>Chris Muir</dc:creator>
		<pubDate>Fri, 29 Feb 2008 01:22:25 +0000</pubDate>
		<guid isPermaLink="false">http://awads.net/wp/2008/02/28/two-quick-and-simple-tips-that-will-help-you-write-better-plsql/#comment-52010</guid>
		<description>Hi Eddie

Not sure I agree with you on this one in all cases and you hint that you nearly always use named notation, implying there are cases when you use positional notation.  In particular I'll point out 2 cases where positional notation is typically used:

1) Oracle has a number of predefined functions that we rarely ever use named parameter notation for.  eg upper, lower etc.

2) If you have a simple function with 1 parameter such as get_name(id IN person.id%TYPE), the code is self explanatory without the named notation extension and I think overkill for simple cases:

DECLARE
  person_id person.id%TYPE := 5;
  name person.name%TYPE;
BEGIN
  name := somepackage.get_name(person_id);
END;

Besides these trivial cases, I agree with the rest of your points.  Now you need a post on writing "meaningful parameter names" ;)

Regards,

CM.</description>
		<content:encoded><![CDATA[<p>Hi Eddie</p>
<p>Not sure I agree with you on this one in all cases and you hint that you nearly always use named notation, implying there are cases when you use positional notation.  In particular I&#8217;ll point out 2 cases where positional notation is typically used:</p>
<p>1) Oracle has a number of predefined functions that we rarely ever use named parameter notation for.  eg upper, lower etc.</p>
<p>2) If you have a simple function with 1 parameter such as get_name(id IN person.id%TYPE), the code is self explanatory without the named notation extension and I think overkill for simple cases:</p>
<p>DECLARE<br />
  person_id person.id%TYPE := 5;<br />
  name person.name%TYPE;<br />
BEGIN<br />
  name := somepackage.get_name(person_id);<br />
END;</p>
<p>Besides these trivial cases, I agree with the rest of your points.  Now you need a post on writing &#8220;meaningful parameter names&#8221; <img src='http://awads.net/wp/wp-includes/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' /> </p>
<p>Regards,</p>
<p>CM.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Eddie Awad</title>
		<link>http://awads.net/wp/2008/02/28/two-quick-and-simple-tips-that-will-help-you-write-better-plsql/#comment-52009</link>
		<dc:creator>Eddie Awad</dc:creator>
		<pubDate>Thu, 28 Feb 2008 20:36:20 +0000</pubDate>
		<guid isPermaLink="false">http://awads.net/wp/2008/02/28/two-quick-and-simple-tips-that-will-help-you-write-better-plsql/#comment-52009</guid>
		<description>Hi Cristian,

I believe that named notation is not supported in 10g (and earlier releases) only when you call a function inside a SELECT statement. However, in 11g, this has been fixed. 

Check out the link titled "11g New Features: Efficient PL/SQL Coding" in the post above. There is more information about this towards the end of the page.</description>
		<content:encoded><![CDATA[<p>Hi Cristian,</p>
<p>I believe that named notation is not supported in 10g (and earlier releases) only when you call a function inside a SELECT statement. However, in 11g, this has been fixed. </p>
<p>Check out the link titled &#8220;11g New Features: Efficient PL/SQL Coding&#8221; in the post above. There is more information about this towards the end of the page.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cristian Cudizio</title>
		<link>http://awads.net/wp/2008/02/28/two-quick-and-simple-tips-that-will-help-you-write-better-plsql/#comment-52008</link>
		<dc:creator>Cristian Cudizio</dc:creator>
		<pubDate>Thu, 28 Feb 2008 20:08:45 +0000</pubDate>
		<guid isPermaLink="false">http://awads.net/wp/2008/02/28/two-quick-and-simple-tips-that-will-help-you-write-better-plsql/#comment-52008</guid>
		<description>Eddie, what do you think about the fact that in function calls named notation (to 10g, i don't know 11g) is not supported?
I think that overload may be a good solution but it depends of what do you have to do with the new parameter.

Cheers,
 Cristian</description>
		<content:encoded><![CDATA[<p>Eddie, what do you think about the fact that in function calls named notation (to 10g, i don&#8217;t know 11g) is not supported?<br />
I think that overload may be a good solution but it depends of what do you have to do with the new parameter.</p>
<p>Cheers,<br />
 Cristian</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Eddie Awad</title>
		<link>http://awads.net/wp/2008/02/28/two-quick-and-simple-tips-that-will-help-you-write-better-plsql/#comment-52007</link>
		<dc:creator>Eddie Awad</dc:creator>
		<pubDate>Thu, 28 Feb 2008 18:49:02 +0000</pubDate>
		<guid isPermaLink="false">http://awads.net/wp/2008/02/28/two-quick-and-simple-tips-that-will-help-you-write-better-plsql/#comment-52007</guid>
		<description>Hi Brian,

using named notation is the best approach to invoking a subprogram, whether you overload or not. But, yes, if the goal is not to break existing code when adding new parameters, overloading the routine can accomplish this goal. Thanks for point this out.</description>
		<content:encoded><![CDATA[<p>Hi Brian,</p>
<p>using named notation is the best approach to invoking a subprogram, whether you overload or not. But, yes, if the goal is not to break existing code when adding new parameters, overloading the routine can accomplish this goal. Thanks for point this out.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brian Tkatch</title>
		<link>http://awads.net/wp/2008/02/28/two-quick-and-simple-tips-that-will-help-you-write-better-plsql/#comment-52006</link>
		<dc:creator>Brian Tkatch</dc:creator>
		<pubDate>Thu, 28 Feb 2008 18:09:18 +0000</pubDate>
		<guid isPermaLink="false">http://awads.net/wp/2008/02/28/two-quick-and-simple-tips-that-will-help-you-write-better-plsql/#comment-52006</guid>
		<description>"So, in general, as a best practice, always use named notation when invoking PL/SQL procedures and functions. To avoid breaking existing code, add new parameters with DEFAULT values to the end of the parameter list of existing procedures or functions."

Wouldn't overloading the routine accomplish the same goal?</description>
		<content:encoded><![CDATA[<p>&#8220;So, in general, as a best practice, always use named notation when invoking PL/SQL procedures and functions. To avoid breaking existing code, add new parameters with DEFAULT values to the end of the parameter list of existing procedures or functions.&#8221;</p>
<p>Wouldn&#8217;t overloading the routine accomplish the same goal?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
