Netezza Stored Procedures Guide 1

Netezza Corporation
Corporate Headquarters
26 Forest St., Marlborough, Massachusetts 01752
tel 508.382.8200 fax 508.382.8300 www.netezza.com
Netezza Stored Procedures
Developers Guide
Document Number: 20470-02 Rev. 1
Software Release: 6.0.x
Revised: October 7, 2010
The specifications and information regarding the products described in this manual are subject to change without notice. All statements, information, and
recommendations in this manual are believed to be accurate.
Netezza makes no representations or warranties of any kind, express or implied, including, without limitation, those of merchantability, fitness for a partic-
ular purpose, and non infringement, regarding this manual or the products' use or performance. In no event will Netezza be liable for indirect, incidental,
consequential, special, or economic damages (including lost business profits, business interruption, loss or damage of data, and the like) arising out of the
use or inability to use this manual or the products, regardless of the form of action, whether in contract, tort (including negligence), breach of warranty, or
otherwise, even if Netezza has been advised of the possibility of such damages.
Netezza, the Netezza logo, the circle-N logo, TwinFin, Skimmer, Snippet Blades, S-Blades, NPS, Snippet, Snippet Processing Unit, SPU, Snippet Process-
ing Array, SPA, Performance Server, Netezza Performance Server, Asymmetric Massively Parallel Processing, AMPP, Intelligent Query Streaming and other
marks are trademarks or registered trademarks of Netezza Corporation in the United States and/or other countries. All rights reserved.
Red Hat is a trademark or registered trademark of Red Hat, Inc. in the United States and/or other countries.
Linux is a trademark or registered trademark of Linus Torvalds in the United States and/or other countries.
D-CC, D-C++, Diab+, FastJ, pSOS+, SingleStep, Tornado, VxWorks, Wind River, and the Wind River logo are trademarks, registered trademarks, or service
marks of Wind River Systems, Inc. Tornado patent pending.
APC and the APC logo are trademarks or registered trademarks of American Power Conversion Corporation.
All document files and software of the above named third-party suppliers are provided "as is" and may contain deficiencies. Netezza and its suppliers dis-
claim all warranties of any kind, express or implied, including, without limitation, those of merchantability, fitness for a particular purpose, and non
infringement.
In no event will Netezza or its suppliers be liable for indirect, incidental, consequential, special, or economic damages (including lost business profits, busi-
ness interruption, loss or damage of data, and the like), or the use or inability to use the above-named third-party products, even if Netezza or its suppliers
have been advised of the possibility of such damages.
All other trademarks mentioned in this document are the property of their respective owners.
Document Number: 20470-02
Software Release Number: 6.0.x
Netezza Stored Procedures Developers Guide
Copyright 2001-2010 Netezza Corporation.
All rights reserved.
PostgreSQL
Portions of this publication were derived from PostgreSQL documentation. For those portions of the documentation that were derived originally from Postgr-
eSQL documentation, and only for those portions, the following applies:
PostgreSQL is copyright 1996-2001 by the PostgreSQL global development group and is distributed under the terms of the license of the University of
California below.
Postgres95 is copyright 1994-5 by the Regents of the University of California.
Permission to use, copy, modify, and distribute this documentation for any purpose, without fee, and without a written agreement is hereby granted, pro-
vided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies.
In no event shall the University of California be liable to any party for direct, indirect, special, incidental, or consequential damages, including lost profits,
arising out of the use of this documentation, even if the University of California has been advised of the possibility of such damage.
The University of California specifically disclaims any warranties, including, but not limited to, the implied warranties of merchantability and fitness for a
particular purpose. The documentation provided hereunder is on an "as-is" basis, and the University of California has no obligations to provide maintenance,
support, updates, enhancements, or modifications.
ICU Library
The Netezza implementation of the ICU library is an adaptation of an open source library Copyright (c) 1995-2003 International Business Machines Corpo-
ration and others.
ICU License - ICU 1.8.1 and later
COPYRIGHT AND PERMISSION NOTICE
Copyright (c) 1995-2003 International Business Machines Corporation and others
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, and/or sell copies of the Software,
and to permit persons to whom the Software is furnished to do so, provided that the above copyright notice(s) and this permission notice appear in all cop-
ies of the Software and that both the above copyright notice(s) and this permission notice appear in supporting documentation.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRAN-
TIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE
COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAM-
AGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in
this Software without prior written authorization of the copyright holder.
ODBC Driver
The Netezza implementation of the ODBC driver is an adaptation of an open source driver, Copyright 2000, 2001, Great Bridge LLC. The source code for
this driver and the object code of any Netezza software that links with it are available upon request to source-request@netezza.com
Botan License
Copyright (C) 1999-2008 Jack Lloyd
2001 Peter J Jones
2004-2007 Justin Karneges
2005 Matthew Gregan
2005-2006 Matt Johnston
2006 Luca Piccarreta
2007 Yves Jerschow
2007-2008 FlexSecure GmbH
2007-2008 Technische Universitat Darmstadt
2007-2008 Falko Strenzke
2007-2008 Martin Doering
2007 Manuel Hartl
2007 Christoph Ludwig
2007 Patrick Sona
Redistribution and use in source and binary forms, for any use, with or without modification, of Botan (http://botan.randombit.net/license.html) is permitted
provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions, and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation and/
or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR(S) "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ARE DISCLAIMED.
IN NO EVENT SHALL THE AUTHOR(S) OR CONTRIBUTOR(S) BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CON-
SEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBIL-
ITYOF SUCH DAMAGE.
Regulatory Notices
Install the NPS system in a restricted-access location. Ensure that only those trained to operate or service the equipment have physical access to it. Install
each AC power outlet near the NPS rack that plugs into it, and keep it freely accessible.
Provide approved 30A circuit breakers on all power sources.
Product may be powered by redundant power sources. Disconnect ALL power sources before servicing.
High leakage current. Earth connection essential before connecting supply. Courant de fuite lev. Raccordement la terre indispensable avant le raccor-
dement au rseau.
FCC - Industry Canada Statement
This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to part 15 of the FCC rules. These limits are
designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment gen-
erates, uses, and can radiate radio-frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful
interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case users will be
required to correct the interference at their own expense.
This Class A digital apparatus meets all requirements of the Canadian Interference-Causing Equipment Regulations.
Cet appareil numrique de la classe A respecte toutes les exigences du Rglement sur le matriel brouilleur du Canada.
WEEE
Netezza Corporation is committed to meeting the requirements of the European Union (EU) Waste Electrical and Electronic Equipment (WEEE) Directive.
This Directive requires producers of electrical and electronic equipment to finance the takeback, for reuse or recycling, of their products placed on the EU
market after August 13, 2005.
CE Statement (Europe)
This product complies with the European Low Voltage Directive 73/23/EEC and EMC Directive 89/336/EEC as amended by European Directive 93/68/EEC.
Warning: This is a class A product. In a domestic environment this product may cause radio interference in which case the user may be required to take
adequate measures.
VCCI Statement
VCCI
A

v
Contents
Preface
1 Introduction to Stored Procedures
Stored Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
NZPLSQL Language. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
SQL Commands for Stored Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Stored Procedures Input and Return Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
How to Create and Use a Stored Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
How to Execute a Stored Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Best Practices for Developers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Cross-Database Access to Stored Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Block Quoting Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
SQL Restrictions within the Stored Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Best Practices for Netezza Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Backing Up and Restoring Stored Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Upgrading and Patching Netezza Systems that Have Stored Procedures . . . . . . . . 1-7
Downgrading Netezza Systems with Stored Procedures . . . . . . . . . . . . . . . . . . . . 1-7
2 NZPLSQL Statements and Grammar
NZPLSQL Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Variables and Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Parameter Passing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
Argument List and Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
Variable Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Data Types and Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
Array Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Expressions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Literals and Math Operations in Expressions. . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Calling Another Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Executing Dynamic Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
vi
Obtaining Other Results Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
Returning From a Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Control Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Conditional Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Iterative Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
Working with Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
Iterating Through Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
Aborting and Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21
Exceptions and Error Messages Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22
Returning a Result Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23
Managing Large Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25
Advanced Development Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25
Extending the Language with UDFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25
Tips and Developer Best Practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-26
3 Creating and Managing Stored Procedures
Managing User Account Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Granting Create Permission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Granting All Object Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Revoking Create Permission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Managing Alter Permission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Managing Execute Permission. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Managing Drop Permission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Creating a Stored Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Design a Stored Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Create a Stored Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Understanding Size-Specific, Generic, and Variable Argument Procedures . . . . . . 3-5
Obfuscating the Procedure Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Calling or Invoking a Stored Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Altering a Stored Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Commenting on a Stored Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
Dropping a Stored Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
Showing Information About a Stored Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
NzAdmin UI for Stored Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
vii
Appendix A: SQL Reference
ALTER PROCEDURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Synopsis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2
Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3
Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4
CALL and EXEC[UTE [PROCEDURE]] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4
Synopsis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4
Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4
Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5
Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5
CREATE [OR REPLACE] PROCEDURE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6
Synopsis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6
Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6
Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8
Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8
DROP PROCEDURE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9
Synopsis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9
Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9
Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-10
Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-10
SHOW PROCEDURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-10
Synopsis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-10
Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-11
Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-11
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-11
Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-12
Appendix B: Stored Procedure Examples
Variable Argument Stored Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1
Example of Simulating an Anonymous Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-2
Index
viii
ix
List of Tables
Table 2-1: Supported Data Types for Variables . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
Table A-1: Stored Procedure SQL Commands. . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Table A-2: ALTER PROCEDURE Input. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2
Table A-3: ALTER PROCEDURE Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2
Table A-4: CALL and EXEC[UTE [PROCEDURE]] Input . . . . . . . . . . . . . . . . . . . A-4
Table A-5: CALL and EXEC[UTE [PROCEDURE]] Output . . . . . . . . . . . . . . . . . . A-4
Table A-6: CREATE OR REPLACE PROCEDURE Input . . . . . . . . . . . . . . . . . . . A-6
Table A-7: CREATE [OR REPLACE] PROCEDURE Output . . . . . . . . . . . . . . . . . A-7
Table A-8: DROP PROCEDURE Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9
Table A-9: DROP PROCEDURE Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9
Table A-10: SHOW PROCEDURE Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-11
Table A-11: SHOW PROCEDURE Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-11
x
xi
Preface
The Netezza Stored Procedures Developers Guide describes how to create and use stored
procedures on a Netezza data warehouse appliance.
About This Guide
This guide is written for Netezza personnel and users who plan to create and use stored
procedures. The guide contains the following topics:
The Purpose of This Guide
This guide describes how to create stored procedures on a Netezza system using the
Netezza procedural language, NZPLSQL. It provides an overview of the language and state-
ments, and how to create, alter, and drop procedures using Netezza SQL commands.
To use this guide, you should be very familiar with the Netezza systems and architecture, as
well as Netezza SQL commands and how to access a Netezza database. You should also be
familiar with the general concepts of stored procedures, how to create structured language
programs, and how to debug applications.
Symbols and Conventions
This guide uses the following typographical conventions:
Italics for terms, and user-defined variables such as file names
Upper case for SQL commands; for example INSERT, DELETE
Bold for command line input; for example, nzsystem stop
Topics See
An overview of stored procedures, their use,
and how to develop them for a Netezza system
Introduction to Stored Procedures on
page 1-1
A description of the NZPLSQL language
statements
NZPLSQL Statements and Grammar on
page 2-1
How to create, manage, and drop stored pro-
cedures using SQL commands and the
NzAdmin interface
Creating and Managing Stored Proce-
dures on page 3-1
A reference of the new Netezza SQL com-
mands for creating and managing stored
procedures
SQL Reference on page A-1
Examples of stored procedures Stored Procedure Examples on
page B-1
xii
If You Need Help
If you are having trouble using the Netezza appliance, you should:
1. Retry the action, carefully following the instructions given for that task in the
documentation.
2. Go to the Netezza Knowledge Base at https://knowledge.netezza.com. Enter your sup-
port username and password. You can search the knowledge base or the latest updates
to the product documentation. Click Netezza HelpDesk to submit a support request.
3. If you are unable to access the Netezza Knowledge Base, you can also contact Netezza
Support at the following telephone numbers:
North American Toll-Free: +1.877.810.4441
United Kingdom Free-Phone: +0.800.032.8382
International Direct: +1.508.620.2281
Refer to your Netezza maintenance agreement for details about your support plan choices
and coverage.
Netezza Welcomes Your Comments
Let us know what you like or dislike about our manuals. To help us with future versions of
our manuals, we want to know about any corrections or clarifications that you would find
useful.
Include the following information:
The name and version of the manual that you are using
Any comments that you have about the manual
Your name, address, and phone number
Send us an e-mail message using the following address: doc@netezza.com
The doc alias is reserved exclusively for reporting errors and omissions in our
documentation.
We appreciate your suggestions.
1-1
C H A P T E R 1
Introduction to Stored Procedures
Whats in this chapter
Stored Procedures
How to Create and Use a Stored Procedure
How to Execute a Stored Procedure
Best Practices for Developers
Best Practices for Netezza Administrators
This chapter provides an overview of the support for stored procedures in the Netezza
family of data warehouse appliances. Stored procedure support is available in Netezza
Release 4.6 and later. This guide describes changes available in Release 6.0.x and later.
Stored Procedures
Netezza stored procedures combine the benefits of SQL to query and manipulate database
information with the benefits of a procedural programming language to handle data pro-
cessing, transaction logic, and application branching behaviors.
For example, if you have a database that contains customer information, inventory, and
sales records, you might also have an application that processes the sale of an item in
inventory. When an order request arrives, the application might be designed to query the
database to determine how many items of that type are available in inventory, and then to
take actions such as the following:
If the available inventory is less than the order number, the application processes the
request for the available number and notifies an order administrator to order more
inventory to complete the purchase.
If the available inventory is greater than the order request, the application processes
the order and updates the database to show the reduction in the current inventory.
If the inventory is discontinued, the application saves the order request and returns a
message that the item is no longer available. It may also query for related or replace-
ment inventory to report alternative merchandise.
While such an application could be managed with a third-party business application that
accesses the Netezza database to perform these tasks, you can also use Netezza stored pro-
cedures to encapsulate this application as an object in the Netezza database. SQL provides
the power to access and update the database information on the host, and the procedure
language provides the logic for if-then-else branching and application processing.
1-2 20470-02 Rev. 1
Because the application resides on the Netezza host, the application performance can ben-
efit from its location onsite by avoiding the network time between an application client
system and the Netezza host. The application itself also becomes easier to maintain, as it
resides in only one location (the Netezza host) and thus versioning and updates need only
be made in one place to keep the application up-to-date for all users.
With Netezza stored procedures, you can also take advantage of security and access bene-
fits. Stored procedures can be defined to run with the credentials of the user who created
the procedure or the credentials of the user who is running the procedure. The procedure
manages the access to information contained in various base tables and views. You can
grant a user permission to run a stored procedure without granting that user explicit access
to underlying tables or views.
NZPLSQL Language
You implement stored procedures on the Netezza host by creating applications using the
NZPLSQL language. NZPLSQL is an interpreted language which is based on Postgres
PL/pgSQL language and designed for the Netezza host environment.
NZPLSQL is a scripting language embedded in SQL. As a procedural language, it has
branch, loop, and subprogram structures while SQL provides the main program. The sub-
programs, known as procedures, can take arguments and declare internal variables. Once
stored in a database, these procedures can be called from within other databases on the
same Netezza host.
The NZPLSQL language provides for the following types of procedural logic:
Conditionals (if/else)
Looping (while, for)
Execution of SQL (including dynamic SQL)
Variables
Returning a scalar result or a result set
Input arguments
Execution in the calling context (session and transaction)
Extending functionality (adding NZPLSQL library routines)
SQL Commands for Stored Procedures
To support stored procedures in the Netezza database, the Netezza SQL language has been
extended to include new commands for stored procedures:
ALTER PROCEDURE
CALL or EXEC[UTE[ PROCEDURE]]
CREATE [OR REPLACE] PROCEDURE
DROP PROCEDURE
SHOW PROCEDURE
You can use any SQL tool that supports ODBC, JDBC, OLE-DB to enter these commands.
This document contains examples that use the nzsql command line tool.
20470-02 Rev. 1 1-3
Appendix A, SQL Reference, describes these commands and their syntax in detail. In
addition to these procedure-specific commands, you can also use the commands GRANT
and REVOKE to permit or deny access to procedures, as well as COMMENT ON to add
descriptions and details to the procedure definitions. For more information about managing
procedures, refer to Chapter 3, Creating and Managing Stored Procedures.
Stored Procedures Input and Return Types
Netezza stored procedures are a hybrid between functions and procedures (as defined by
the SQL:2003 standard for SQL-invoked routines). In the Netezza implementation, an
NZPLSQL stored procedure takes only input arguments and supports a return value as
functions do. Unlike functions, a stored procedure must be called using CALL or a similar
construct, and it is not allowed in the usual query locations where a built-in or standard
function is allowed.
Note: A stored procedure can also be designed to return a result set. For more information,
see Returning a Result Set on page 2-23.
As a high-level summary, follow these steps to create and use a stored procedure. These
steps are described in more detail in Chapter 3, Creating and Managing Stored
Procedures.
1. Design the stored procedure logic and operation.
2. Define the stored procedure object using the CREATE [OR REPLACE] PROCEDURE
command.
3. Run or execute the procedure from the SQL command prompt.
As with other Netezza objects, the Netezza admin user can create, list, and execute stored
procedures by default. The admin user may also grant other users permission to create, list,
and execute stored procedures on the Netezza system. For more information about permis-
sions, see Managing User Account Permissions on page 3-1.
How to Execute a Stored Procedure
You execute a stored procedure in the SQL command using either the CALL or EXEC[UTE[
PROCEDURE]] commands. For example, if you have a stored procedure named update-
acct(), you can run it using any of the following commands:
MYDB( USER) => CALL updateacct();
MYDB( USER) => EXEC updateacct();
MYDB( USER) => EXECUTE updateacct();
MYDB( USER) => EXECUTE PROCEDURE updateacct();
You can also use the SELECT command to execute a procedure; however, you cannot spec-
ify a FROM clause. For example:
MYDB( USER) => SELECT updateacct();
To execute the procedure, the user must be the owner of or have permission to execute the
updateacct() procedure. For more information about the CALL and EXEC[UTE[ PROCE-
DURE]] commands, refer to Appendix A, SQL Reference.
1-4 20470-02 Rev. 1
The following sections describe some best practices for users who develop stored
procedures.
Security Considerations
When you define a stored procedure, you can specify whether the Netezza system should
execute the procedure using the ID of the owner who created the stored procedure or the ID
of the user who runs the procedure. This allows you an additional layer of security (or
expanded access) for the data processed by the stored procedure.
For example, if the admin user created the stored procedure and specified execute as
owner permissions, which is the default, then any other user who is permitted to execute
the procedure will run the procedure as the admin user. This could, for example, allow
the user to see results from tables or views that he or she does not have permission to
access using SQL directly.
If the procedure should access only the data that the user is permitted to see, the stored
procedure should be defined as execute as caller. In this case, the procedure uses the
user ID of the calling user, and thus the access permissions of that user.
Cross-Database Access to Stored Procedures
When you create a stored procedure using the CREATE [OR REPLACE] PROCEDURE com-
mand, the command adds the procedure to the database to which you are connected. You
can define the stored procedure in more than one database if necessary.
Typically, most users are logged in to the database that contains the stored procedure that
they plan to run. However, the Netezza system allows for cross-database access of stored
procedures using two methods:
Using fully-qualified object names when calling a procedure object that resides within
a different database, for example:
MYDB( ADMI N) => EXEC OTHERDB..UPDATEACCT();
Using the PATH SQL session variable to specify the databases to search to find a proce-
dure. To use the PATH session variable, you enter a command similar to the following:
MYDB( ADMI N) => SET PATH = <elem> [, <elem>];
The <elem> value can be a database name or the variables CURRENT_CATALOG,
CURRENT_USER, CURRENT_SCHEMA or CURRENT_PATH. Anything you specify as
<elem> must resolve to a database name.
For example:
MYDB( ADMI N) => SET PATH = mydb, nzdb, customer;
SET VARI ABLE
To display the PATH value, use the following command:
MYDB( ADMI N) => SELECT CURRENT_PATH;
CURRENT_PATH
- - - - - - - - - - - - - - - - - -
MYDB, NZDB, CUSTOMER
( 1 r ow)
20470-02 Rev. 1 1-5
The Netezza system uses the PATH variable during the lookup of any unqualified proce-
dures. It searches the current database if PATH is not set; otherwise it searches the
databases specified in PATH, in the order that they are specified. The Netezza system uses
the first match that it finds, even if a better match might exist in a subsequent database. A
poorer match is one that might require implicit casting of arguments or that causes an error
due to multiple potential matches. Note that PATH searches databases, not schemas, as
there is no schema support for this capability. Also, the Netezza system uses the PATH ses-
sion variable to find only stored procedures, user-defined functions (UDFs), and user-
defined aggregates (UDAs). Other object types are not supported.
It is important to note that if a stored procedure is invoked from a different database,
unqualified objects will bind to objects in the invoking database, not in the database where
the stored procedure resides. Note that unqualified stored procedures, UDFs, and UDAs are
exceptions to this rule because the Netezza system first uses the PATH variable to search
for those three object types before it searches within the invoking database.
If you plan to invoke cross-database calls to stored procedures that access data in other
databases, make sure that the stored procedure uses fully-qualified object names to refer
to those data objects.
Note: Certain types of operations will not work across databases, such as insert, update,
and delete operations. For any procedure which contains those types of operations, make
sure that you are connected to the database where the stored procedure is defined.
Block Quoting Support
Since stored procedures are defined as a block or body of numerous lines of text, Netezza
provides a block-quoting mechanism to help ease the definition of the procedure body as
well as to make the content more readable for debugging and learning.
A section of text bounded by BEGIN_PROC and END_PROC is a block quote. An example
follows:
CREATE OR REPLACE PROCEDURE name( ) RETURNS I NT4 LANGUAGE NZPLSQL AS
BEGI N_PROC
DECLARE
st r i ng var char ;
BEGI N
st r i ng : = ' Thi s st r i ng i s quot ed' ;
END;
END_PROC;
As shown in the example, single quotes are not escaped within the block-quoted string. The
string content is always written literally. Backslashes have no special escape meaning.
Note: The stored procedure body is in clear text format by default. Permitted users can use
the SHOW PROCEDURE VERBOSE command and interfaces such as NzAdmin to review
the stored procedure. If necessary, you can hide the procedure code when you create the
procedure. For more information, see Obfuscating the Procedure Body on page 3-7.
Block quotes are intended for use only in NZPLSQL body quoting or stored procedure invo-
cation. The execution commands CALL and EXEC[UTE[ PROCEDURE]] support them,
although SELECT does not. They can be used inside a stored procedure body to build DDL
statements where they are allowed, but they have no quoting implications inside the body.
If they are used inside the body, make sure that there are an equal number of both key-
words and that they match (a BEGIN_PROC appears before the corresponding END_PROC)
to avoid errors. If your program logic dictates that they are not matching, they must be bro-
ken up (that is, 'BEGIN_' || 'PROC').
1-6 20470-02 Rev. 1
Both BEGIN_PROC and END_PROC can appear inside a single or double-quoted string in
normal SQL statements, as long as the SQL statements are not inside a block quote. For
example:
sel ect " BEGI N_PROC" f r om<t abl e>;
i nser t i nt o <t abl e> val ues ( ' BEGI N_PROC' ) ;
If you want to do this inside a block quote body, then you must have a matching
END_PROC. For example:
BEGI N_PROC
DECLARE
BEGI N
st r i ng : = ' Thi s st r i ng i s quot ed' ;
- - Thi s comment i s t he mat ch f or bel ow BEGI N_PROC
i nser t i nt o va val ues ( ' END_PROC' ) ;
END;
END_PROC;
Because nested BEGIN_PROC and END_PROC keywords have no quoting implications, the
following example is not supported:
BEGI N_PROC
DECLARE
BEGI N
- - The next st at ement i s a synt ax er r or si nce i t i s not quot ed
st r i ng : = BEGI N_PROC Thi s st r i ng i s not quot ed END_PROC;
END;
END_PROC;
SQL Restrictions within the Stored Procedure
Within the body of a stored procedure, you can use most SQL commands to perform tasks
relating to database objects. However, you cannot use SQL commands that are prohibited
for use within a BEGIN/COMMIT transaction block. For a description of the transaction
control practices and command restrictions, see the Netezza Database Users Guide.
The following sections describe some best practices for Netezza administrators who man-
age Netezza systems that have stored procedures.
Backing Up and Restoring Stored Procedures
Any stored procedures that you create are backed up and restored by the Netezza backup
and restore operations. If you backup and restore obfuscated procedures, those restored
procedures remain obfuscated. If you restore a database to a system that is running a
release which does not support obfuscated procedures or VARARGS, for example, those
procedures will not run and the queries that use them will return a syntax error.
If you drop a database, note that all the objects defined in the database including stored
procedures are likewise dropped. As a best practice, you should keep backup copies of
your source CREATE OR REPLACE PROCEDURE definitions in a safe location outside of
20470-02 Rev. 1 1-7
the Netezza system. Make sure that you have recent backups of your Netezza systems in
the event that you need to recover from an accidental deletion or change, or to restore
Netezza services as part of a disaster recovery situation.
Upgrading and Patching Netezza Systems that Have Stored Procedures
There are no special requirements or procedures necessary to preserve any stored proce-
dures during a service pack update or an upgrade to a new release. The stored procedures
should continue to operate in the same manner on the newly updated or upgraded system
as on the previous release.
If you downgrade the system, note that your stored procedures should continue to run if the
downgrade release also supports stored procedures. However, if you downgrade from a
Release 6.0.x version to a previous release such as 5.0.x which does not support obfus-
cated procedures or VARARGS, for example, those procedures will not run and the queries
that use them will return a syntax error.
If the new release or service pack introduces any new features or changes that could affect
the operation of stored procedures, Netezza will describe the changes in the release notes
for the service pack or release. Before you install any new release or service pack, you
should review the release notes to familiarize yourself with any new features, changes,
fixes, and known issues for that release. You should also make sure that you have a recent
backup of your Netezza system before you upgrade the system.
Downgrading Netezza Systems with Stored Procedures
If you downgrade your Netezza release, note that downgrades to any releases prior to
Release 4.6 will drop all stored procedures automatically. If you downgrade to a release
that supports stored procedures, the procedures should continue to work after the down-
grade, unless your stored procedures use features that were available only in the later
release.
1-8 20470-02 Rev. 1
2-1
C H A P T E R 2
NZPLSQL Statements and Grammar
NZPLSQL Structure
Comments
Variables and Constants
Array Variables
Expressions
Statements
Control Structures
Working with Records
Aborting and Messages
Exceptions and Error Messages Support
Returning a Result Set
Advanced Development Topics
This chapter describes the NZPLSQL language, its structure, and how to use the language
to create stored procedures.
NZPLSQL is very similar to the Postgres PL/pgSQL language. Some of the language
descriptions in this chapter leverage the Postgres PL/pgSQL documentation. However,
NZPLSQL has some differences which are based on the Netezza systems design and envi-
ronment. NZPLSQL also includes some extensions to assist users who may be migrating
stored procedures written in other languages to the Netezza environment.
NZPLSQL Structure
NZPLSQL is a block structured language. A block is defined as follows:
[ <<l abel >>]
[ DECLARE
declarations]
BEGI N
statements
[ EXCEPTI ON WHEN OTHERS THEN
handler statements]
END;
2-2 20470-02 Rev. 1
The statements section of a block can contain zero, one, or more sub-blocks. A sub-block is
used for logical grouping or to localize variables to a small group of statements.
All of the keywords and identifiers are case-insensitive and can be used in mixed upper-
and lower-case mode. Identifiers are automatically converted to uppercase, as they are in
general SQL statements, unless they are enclosed in quotes to keep them case-sensitive.
The variables declared in the declarations section preceding a block are initialized to their
default values every time the block is entered, not just once per procedure call.
Note: Be careful not to confuse the use of BEGIN/END for grouping statements in
NZPLSQL with the BEGIN/END SQL database commands for transaction control. The
NZPLSQL BEGIN/END keywords are used only for grouping; they do not start or end a
transaction. Procedures are always executed within a transaction established by an outer
querythey cannot start or commit transactions, since Netezza SQL does not have nested
transactions.
Comments
There are two types of comments in NZPLSQL.
A double dash (--) starts a comment that extends to the end of the line. For example:
- - Thi s i s a comment l i ne.
A forward-slash asterisk pair (/*) starts a block comment, which extends to the next
occurrence of the ending sequence which is an asterisk forward-slash (*/) pair. For
example:
/ * Thi s i s a bl ock comment ,
whi ch can span mul t i pl e l i nes.
Any code i nsi de t he bl ock such as:
ur l var char : = ' ht t p: / / www. net ezza. com'
i s i gnor ed. */
Block comments cannot be nested, but double dash comments can be enclosed in a block
comment. Note that a double dash can hide the block comment delimiters /* and */.
All of the variables, rows, and records that are used in a block or its sub-blocks must be
declared in the declarations section of a block. (There are some exceptions, namely the
loop variable of a FOR loop that iterates over a range of integer values, and some built-in
variables like FOUND, ROW_COUNT, and LAST_OID.)
NZPLSQL variables can have any SQL datatype, such as INTEGER, VARCHAR, and CHAR.
Some sample variable declarations follow:
user _i d I NTEGER;
quant i t y NUMERI C( 5, 2) ;
ur l VARCHAR;
A variable declaration has the following syntax:
name [ CONSTANT ] type [ NOT NULL ] [ { DEFAULT | : = } value ] ;
20470-02 Rev. 1 2-3
The DEFAULT clause, if included, specifies the initial value assigned to the variable
when the block is entered. If a DEFAULT clause is not specified, the variable uses the
SQL NULL value as its default.
The CONSTANT option means that the variable cannot be changed; its value remains
constant for the duration of the block.
If NOT NULL is specified, an assignment of a NULL value results in a runtime error.
Since the default value of all variables is the SQL NULL value, all variables declared as
NOT NULL must also specify a non-null default value.
When specifying types in declarations, NUMERIC may be specified with or without a preci-
sion and scale. CHAR, NCHAR, VARCHAR, and NVARCHAR may be specified with or
without a size. When these types are specified with a size or a precision/scale, assignment
to the variable will follow normal cast rules. If they are specified without sizes, assignment
will preserve the original source size or precision/scale.
The default value is evaluated each time the procedure is called. So assigning now() to a
variable of type timestamp causes the variable to be set to the time of the actual procedure
call, not the time when the procedure was precompiled into its bytecode.
Some examples of variable assignments follow:
quant i t y I NTEGER : = 32;
ur l var char : = ' ht t p: / / mysi t e. com' ;
user _i d CONSTANT I NTEGER : = 10;
Using the %TYPE and %ROWTYPE attributes, you can declare variables with the same
datatype or structure of another database item (for example, a table field).
%TYPE provides the datatype of a variable or database column. You can use this to declare
variables that will hold database values. For example, if you have a column named user_id
in your users table, you can declare a variable with the same datatype as user_id as follows:
user _i d user s. user _i d%TYPE;
By using %TYPE, you do not have to know the datatype of the structure that you are refer-
encing. Also, if the datatype of the referenced item changes in the future (for example, you
change your table definition of user_id to become a REAL), you do not have to change your
procedure definition.
You can declare a row with the structure of a given table, as follows:
name table%ROWTYPE;
The table value must be an existing table or view name of the database. The fields of the
row are accessed using the dot notation.
Only the user attributes of a table row are accessible in the row. You cannot access an OID
or other system attribute because the row could be from a view. The fields of the rowtype
inherit the table's sizes or precision for CHAR, NCHAR, and NUMERIC data types, as
applicable.
2-4 20470-02 Rev. 1
Parameter Passing
In NZPLSQL, parameters are not named. Instead, only the data types are passed, and
parameters are referenced via their position. To name parameters, use the ALIAS FOR syn-
tax. For example:
CREATE OR REPLACE PROCEDURE p1 ( i nt , var char ( ANY) ) RETURNS i nt
LANGUAGE NZPLSQL AS
BEGI N_PROC
DECLARE
pI d ALI AS FOR $1;
pName ALI AS FOR $2;
BEGI N
I NSERT I NTO t 1 SELECT * FROM t 2 WHERE i d = pI d;
The example highlights the recommended convention to name parameters with a p prefix
to differentiate them from variables. This convention is helpful because parameters are
constant and cannot be modified. If a parameter must be updated (for example, to assign it
a default value if it is null), assign the parameter to a variable and update the variable. For
example:
DECLARE
pI d ALI AS FOR $1;
vI D i nt eger ;
BEGI N
vI d : = I SNULL( pI d, 0) ;
I NSERT I NTO t 1 SELECT * FROM t 2 WHERE i d = vI d;
Argument List and Variables
The arguments passed as input to procedures can be identified using the names $1 (first
argument), $2 (second argument), and so on. You can also use the $var notation, which
takes the integer value of var to identify the input value specified in that order position.
You can specify from 0 to 64 arguments. If you specify VARARGS in the input argument
list, users can input any number of arguments up to a maximum of 64.
Netezza saves the OIDs of the input arguments in the PROC_ARGUMENT_TYPES array.
The array has the same size as the number of parameters that are passed to the stored pro-
cedure. Its elements are of type OID and contain the OID type of the corresponding input
argument. You can use the array to obtain the number and type of each argument.
For example:
CREATE OR REPLACE PROCEDURE t est ( VARARGS)
RETURNS I NT4
LANGUAGE NZPLSQL
AS
BEGI N_PROC
DECLARE
num_ar gs i nt 4;
t yp oi d;
i dx i nt 4;
BEGI N
num_ar gs : = PROC_ARGUMENT_TYPES. count ;
RAI SE NOTI CE ' Number of ar gument s: %' , num_ar gs;
f or i I N 0 . . PROC_ARGUMENT_TYPES. count - 1 LOOP
t yp : = PROC_ARGUMENT_TYPES( i ) ;
i dx : = i +1;
20470-02 Rev. 1 2-5
RAI SE NOTI CE ' ar gument $%i s t ype %and has t he val ue ' ' %' ' ' ,
i dx, t yp, $i dx;
END LOOP;
END;
END_PROC;
A sample call follows:
MYDB( USR2) => CALL TEST (1, 3, 9::bigint, 'test value', 324.56);
NOTI CE: Number of ar gument s: 5
NOTI CE: ar gument $1 i s t ype 23 and has t he val ue ' 1'
NOTI CE: ar gument $4 i s t ype 705 and has t he val ue ' t est val ue'
NOTI CE: ar gument $5 i s t ype 1700 and has t he val ue ' 324. 56'
t est
- - - - - -
( 1 r ow)
Variable Scoping
When you explicitly declare a new variable (or name), the scope of the variable is the block
in which it is defined. For example, the following sample defines a variable named val in
the <<outer>> blocks DECLARE section, and then defines another val variable in the
<<inner>> blocks DECLARE section. Although the variables have the same name, these
are two different variables:
<<out er >>
DECLARE
val i nt 4;
BEGI N
val : = 5;
<<i nner >>
DECLARE
val i nt 4;
BEGI N
val : = 7;
RAI SE NOTI CE ' i nner val ! = out er val %%' , val , out er . val ;
END;
RAI SE NOTI CE ' out er val i s 5 %' , val ;
END;
In this example, note that the block labels inner and outer can be used to identify a spe-
cific val variable using its fully-qualified variable name. If you create this as a stored
procedure and run it, you would see output similar to the following:
MYDB( USER) => call vals();
NOTI CE: i nner val ! = out er val 7 5
NOTI CE: out er val i s 5 5
VALS
- - - - - -
( 1 r ow)
When you declare variables for loop iterators, which are described in Loop Statement on
page 2-17, note that the iterator variables have their own unique scope. For example, you
could use a variable named val as a loop iterator. Using the same sample procedure, this
would give you three unique val variables in your procedure, as follows:
2-6 20470-02 Rev. 1
<<out er >>
DECLARE
val i nt 4;
BEGI N
val : = 5;
<<i nner >>
DECLARE
val i nt 4;
BEGI N
val : = 7;
RAI SE NOTI CE ' i nner val ! = out er val %%' , val , out er . val ;
FOR val I N 1. . 10 LOOP
- - Not e t hat t hi s i s a NEWval var i abl e f or t he l oop.
RAI SE NOTI CE ' The val ue of val i s %' , val ;
END LOOP;
RAI SE NOTI CE ' i nner val i s st i l l 7. Val ue %' , i nner . val ;
END;
RAI SE NOTI CE ' out er val i s st i l l 5. Val ue %' , val ;
END;
Sample output for this stored procedure follows:
MYDB( USER) => call vals();
NOTI CE: i nner val ! = out er val 7 5
NOTI CE: The val ue of val i s 1
NOTI CE: i nner val i s st i l l 7. Val ue 7
NOTI CE: i nner val i s st i l l 5. Val ue 5
VALS
- - - - - -
( 1 r ow)
As shown in the output, the val variable of the loop iterator has its own scope. It has its own
value and does not affect the other two val definitions. Within the loop, if you need to refer
to a specific variable that is defined outside the for loop, you can use the fully qualified
form of the variable name (label.variable).
Data Types and Aliases
Table 2-1 lists the supported data types by their preferred name form, and includes sup-
ported aliases and some notes about the values. For more information about the data types
and values, see the Netezza Database Users Guide.
20470-02 Rev. 1 2-7
Table 2-1: Supported Data Types for Variables
Data Type Alias Name(s) Notes
BOOLEAN BOOL A boolean field can store true values, false values,
and null. You can use the following words to spec-
ify booleans: true or false, on or off, 0 or 1,
'true or false, t or f, on or off, yes or no.
CHAR CHARACTER,
CHAR(n),
CHARACTER(n)
Fixed length character string, blank padded to
length n. If you do not specify n, the default is an
unsized CHAR value. The maximum character
string size is 64,000.
VARCHAR CHARACTER VARY-
ING, VARCHAR(n),
CHARACTER VARY-
ING(n), CHAR
VARYING(n)
Variable length character string to a maximum
length of n. If you do not specify n, the default is
an unsized VARCHAR value. There is no blank
padding, and the value is stored as entered. The
maximum character string size is 64,000.
NCHAR NATIONAL CHAR-
ACTER, NATIONAL
CHAR(n),
NCHAR(size)
Fixed length character string, blank padded to
length n. If you do not specify n, the default is an
unsized NCHAR value. The maximum length is
16,000 characters.
NVARCHAR NATIONAL CHAR-
ACTER VARYING,
NATIONAL CHAR
VARYING,
NATIONAL CHAR
VARYING(n),
NATIONAL CHAR-
ACTER
VARYING(n), and
NVARCHAR(n)
Variable length character string to a maximum
length of n. If you do not specify n, the default is
an unsized NVARCHAR value. The maximum
length is 16,000 characters.
DATE Specifies a day with resolution that spans January
1, 0001 to December 31, 9999 (centered around
2000-01-01).
TIMESTAMP DATETIME Has a date part and a time part, with seconds
stored to 6 decimal positions. The value repre-
sents the number of microseconds since midnight
2000-01-01.
Min: -63,082,281,600,000,000 (00:00:00, 1/1/
0001)
Max: 252,455,615,999,999,999
(23:59:59.999999, 12/31/9999)
2-8 20470-02 Rev. 1
TIME TIME WITHOUT
TIME ZONE
Hours, minutes, and seconds to 6 decimal posi-
tions. Ranging from 00:00:00.000000 to
23:59:59.999999. This is microsecond resolu-
tion that represents the time of day only (midnight
to one microsecond before midnight).
INTERVAL TIMESPAN An interval of time. It has microsecond resolution
and ranges from +/- 178000000 years. The time
part represents everything but months and years
(microseconds) and the month part represents
months and years. For more information see the
section on Netezza interval support in the Netezza
Database Users Guide.
TIME WITH
TIME ZONE
TIMETZ Hours, minutes, seconds to 6 decimal positions,
and time zone offset from GMT. Ranging from
00:00:00.000000+13:00 to 23:59:59.999999-
12:59.
NUMERIC(p,
s)
NUMERIC, DEC,
DEC(p,s), DECI-
MAL(p,s),
DECIMAL
Fixed-point numeric types with precision p and
scale s. Precision can range from 1 to 38, scale
from 0 to the precision.
NUMERIC(p) is equivalent to NUMERIC(p,0).
NUMERIC is an unsized numeric value.
Although decimal is sometimes a distinct SQL
data type, Netezza SQL treats it as an alias for
numeric.
REAL FLOAT(p), FLOAT4 Floating point number with precision p. Precision
values of 1 to 6 are equivalent to FLOAT(6), and
are stored as a 4-byte value.
Netezza SQL prefers the type name real, as
float(p) is considered more of an alias for the pre-
ferred form.
DOUBLE
PRECISION
DOUBLE, FLOAT,
FLOAT(p), FLOAT8
Floating point number with precision p, from 7 to
15. Precision values between 7 and 15 are equiv-
alent to 15 and are stored as an 8-byte value.
Netezza SQL prefers the type name double preci-
sion, as float(p) is considered more of an alias for
the preferred form.
INTEGER INT, INT4 32-bit values in range 2,147,483,648 to
2,147,483,647
BYTEINT INT1 8-bit values in the range 128 to 127
SMALLINT INT2 16-bit values in range 32,768 to 32,767
Table 2-1: Supported Data Types for Variables (continued)
20470-02 Rev. 1 2-9
Array Variables
Array Variables
In addition to normal scalar variables, NZPLSQL also supports array variables. To declare
an array variable, use the following syntax:
name VARRAY( size) OF type;
All of the elements of the array will initially be set to the SQL NULL value for the declared
type. To assign a value to an element, do the following:
name( idx) : = value;
This syntax will raise an exception if the index (idx) is out of bounds. The following meth-
ods are supported:
name. EXTEND( size)
name. COUNT
name. TRI M( size)
The EXTEND method will extend the array by the specified size. If size is omitted, the
default is 1.
COUNT returns the number of elements in the array.
TRIM deletes the last size elements in the array (the default is 1). TRIM and EXTEND will
raise an exception if size is out of bounds.
Array references are allowed almost anywhere variable references are allowed, with the fol-
lowing exceptions:
As an argument to RAISE
As an INTO variable
As the variable in a FOR LOOP
As part of a default value
Expressions
All expressions used in NZPLSQL statements are processed using the backends executor.
Expressions that appear to contain constants could require run-time evaluation (for exam-
ple, using 'now()' for the timestamp type) so it is impossible for the NZPLSQL parser to
identify real constant values other than the NULL keyword. All expressions are evaluated
internally by executing a query such as the following:
SELECT expression
In the expression, occurrences of variable identifiers are substituted by parameters and the
actual values from the variables are passed to the executor in the parameter array. All
expressions used in a NZPLSQL procedure are compiled and cached the first time they are
BIGINT INT8 64-bit values in range
-9,223,372,036,854,775,808 to
9,223,372,036,854,775,807
Table 2-1: Supported Data Types for Variables (continued)
2-10 20470-02 Rev. 1
encountered. (Everything in NZPLSQL is cached, with the exception of variable values and
SQL plans.) If there is a compile error (syntax error), the expression will not be cached. The
cached copy is preserved until one of the following happens:
The procedure body is modified.
The procedure is dropped.
The database session ends.
The type checking done by the Netezza SQL main parser has some side effects to the inter-
pretation of constant values. For example, the following two examples are different in how
constant values are interpreted. The first example follows:
DECLARE
l ogt xt ALI AS FOR $1;
BEGI N
I NSERT I NTO l ogt abl e VALUES ( l ogt xt , ' now( ) ' ) ;
RETURN ' now( ) ' ;
END;
The second example follows:
DECLARE
l ogt xt ALI AS FOR $1;
cur t i me t i mest amp;
BEGI N
cur t i me : = ' now( ) ' ;
I NSERT I NTO l ogt abl e VALUES ( l ogt xt , cur t i me) ;
RETURN cur t i me;
END
In the first example, when the Netezza SQL main parser prepares the plan for the INSERT,
it interprets now() as a timestamp because the target field of logtable is of that type. It will
interpret both instances of now() each time it runs.
In the second example, the Netezza SQL main parser does not know what type now()
should become and therefore it returns a data type of text containing the string now(). Dur-
ing the assignment to the local variable curtime, the NZPLSQL interpreter casts this string
to the timestamp type by calling the text_out() and timestamp_in() functions for the
conversion.
If record fields are used in expressions or statements, the data types of fields should not
change between calls to the same expression or statement.
Literals and Math Operations in Expressions
If your stored procedures perform math operations in expressions, carefully consider the
supported ranges for literals and the possible implicit typecasts that the Netezza system
may perform. These ranges and behaviors could cause unexpected results in complex math
expressions.
For example, all integer literals are 32-bit (signed) numbers by default, which supports a
range of values from -2147483648 to 2147483647. If you perform math operations on a
literal, use caution to check for overflows. For example, the following stored procedure
defines a numeric value n, assigns it the largest supported value (2147483647) and then
adds 1 to the value:
CREATE OR REPLACE PROCEDURE num( ) RETURNS BOOL LANGUAGE NZPLSQL AS
BEGI N_PROC
DECLARE
20470-02 Rev. 1 2-11
Expressions
n NUMERI C;
BEGI N
n : = 2147483647;
RAI SE NOTI CE ' n i s %' , n;
n : = 2147483647 + 1;
END;
END_PROC;
If you create and run this stored procedure, the output is as follows:
NOTI CE: n i s 2147483647
NOTI CE: n i s - 2147483648
The output demonstrates that when a value overflows its maximum range value, the value
wraps to its minimum value and begins again. To avoid this counter-wrap behavior, you
must either use a cast operation to cast n to a higher precision type, or assign values to
intermediate values. For example, the following stored procedure creates the counter-wrap
issue for the numeric value n, but then it uses casts to numerics or bigints to increase the
range of valid values, as follows:
CREATE OR REPLACE PROCEDURE num( ) RETURNS BOOL LANGUAGE NZPLSQL AS
BEGI N_PROC
DECLARE
n NUMERI C;
BEGI N
n : = 2147483647;
n : = 2147483647 + 1;
n : = 2147483647: : numer i c + 1;
n : = 2147483647: : bi gi nt + 1;
n : = 2147483647;
n : = n + 1;
END;
END_PROC;
If you create and run this stored procedure, the output would be similar to the following:
NOTI CE: n i s 2147483647
NOTI CE: n i s - 2147483648
NOTI CE: n i s 2147483648
NOTI CE: n i s 2147483648
NOTI CE: n i s 2147483648
If you use floating point numbers in expressions, Netezza attempts to cast it into a numeric
if possible, with a specific precision and scale that it calculates using internally defined
casting rules.
Because arithmetic operations in a stored procedure are evaluated by invoking the backend
executor, they will be processed as SELECT statements. To more clearly see the calculated
shape of the expression result, it can be helpful to use it to create a table, which can then
be described using the \d command. Printing the results may not provide enough insight to
the resulting datatypes.
In the arithmetic expression that follows, Netezza casts the precision and scale based on
internal Netezza SQL behavior rules:
2-12 20470-02 Rev. 1
DEV( ADMI N) => cr eat e t abl e t est as sel ect ( 1 + 0. 08/ 365) i nt er est ;
I NSERT 0 1
DEV( ADMI N) => \ d t est
Tabl e " TEST"
At t r i but e | Type | Modi f i er | Def aul t Val ue
- - - - - - - - - - +- - - - - - - - - - - - - - +- - - - - - - - - - +- - - - - - - - - - - - - - -
I NTEREST | NUMERI C( 8, 6) | |
Di st r i but ed on hash: " I NTEREST"
In the sample table, the Netezza internal casting rules evaluated the expression 1+0.08/
365 and determined that the field would be a numeric value with 8 digits of precision and
6 of scale. The following command shows the actual value saved in the row:
DEV( ADMI N) => sel ect * f r omTEST;
I NTEREST
- - - - - - - - - -
1. 000219
( 1 r ow)
Another example follows:
DEV( ADMI N) => cr eat e t abl e t est 2 as sel ect ( 4 + 1/ 5) l oanr t ;
I NSERT 0 1
DEV( ADMI N) => \ d t est 2
Tabl e " TEST2"
- - - - - - - - - - +- - - - - - - - - - +- - - - - - - - - - +- - - - - - - - - - - - - - -
LOANRT | I NTEGER | |
Di st r i but ed on hash: " LOANRT"
In the previous example, Netezza is evaluating three integer values (4, 1, and 5). The
Netezza system uses integer as the type for the new column. If you display the column
value, as follows, you can see that the decimal portion of the value was truncated:
DEV( ADMI N) => sel ect * f r omTEST2;
LOANRT
- - - - - - - -
4
( 1 r ow)
A similar example follows, but instead of the expression 1/2, this expression uses the
numeric value .5 instead, as follows:
DEV( ADMI N) => cr eat e t abl e t est 3 as sel ect ( 4 + . 5) l oanr t ;
I NSERT 0 1
Tabl e " TEST3"
- - - - - - - - - - +- - - - - - - - - - - - - - - +- - - - - - - - - - +- - - - - - - - - - - - - - -
LOANRT | NUMERI C( 3, 1) | |
Di st r i but ed on hash: " LOANRT"
LOANRT
- - - - - - - -
4. 5
( 1 r ow)
20470-02 Rev. 1 2-13
Expressions
In this example, the .5 value is interpreted as 0.5, and thus cast to numeric(3,1).
In addition to the casts that can occur when math expressions are parsed, Netezza func-
tions can also cause an implicit typecast. For example, the function sqrt() takes and returns
a double precision value. The following example uses the function to define a table
column:
DEV( ADMI N) => cr eat e t abl e t est 4 as sel ect ( sqr t ( 42) ) ;
I NSERT 0 1
Tabl e " TEST4"
- - - - - - - - - - +- - - - - - - - - - - - - - - - - - +- - - - - - - - - - +- - - - - - - - - - - - - - -
SQRT | DOUBLE PRECI SI ON | |
Di st r i but ed on hash: " SQRT"
SQRT
- - - - - - - - - - - - - - - - -
6. 4807406984079
( 1 r ow)
In the test4 example, the sqrt() function causes Netezza to cast the input integer value to a
double and to return a double.
Keep these behaviors in mind when you work with stored procedures that use arithmetic
expressions to evaluate data. The implicit casts may not provide the value that you would
expect if you evaluated the same arithmetic expression with a calculator. An example
follows:
CREATE OR REPLACE PROCEDURE sp_expr essi ons_numer i c02( ) RETURNS NUMERI C
LANGUAGE NZPLSQL AS
BEGI N_PROC
DECLARE
t hi snum9_2 NUMERI C( 9, 2) ;
mi l l i on NUMERI C( 9, 2) : = 1000000. 00;
t hi snum18 NUMERI C( 18) ;
l i t espeed NUMERI C : = 186282;
t hi snum38 NUMERI C( 38) ;
BEGI N
/ * The f ol l owi ng expr essi on causes i mpl i ci t cast s i n t he mat h
eval uat i on, r educi ng t he pr eci si on and scal e of t he r esul t . */
t hi snum9_2 : = mi l l i on * ( 1 + 0. 08/ 365) ^( 365 * 20) ;
RAI SE NOTI CE ' t hi snum9_2 == %' , t hi snum9_2;
/ * The f ol l owi ng expr essi on uses an expl i ci t cast t o i ncr ease
t he pr eci si on and scal e of t he i nt er medi at e eval uat i on. */
t hi snum9_2 : = mi l l i on * ( 1 + 0. 08: : numer i c( 20, 15) / 365) ^( 365 * 20) ;
RAI SE NOTI CE ' t hi snum9_2 == %' , t hi snum9_2;
/ * The f ol l owi ng expr essi on uses t he numer i c l i t er al l i t espeed t o
conver t t he speed of l i ght f r ommi l es per sec t o mi l es per
year . */
t hi snum18 : = l i t espeed * 60 * 60 * 24 * 365. 25;
RAI SE NOTI CE ' t hi snum18 == %' , t hi snum18;
/ * The f ol l owi ng expr essi on uses t he i nt eger 186282 t o conver t
l i ght speed f r ommi l es per sec t o mi l es per year . I n t he
r i ght - si de eval uat i on, however , t he val ues over f l owed t he
2-14 20470-02 Rev. 1
upper l i mi t of an i nt sever al t i mes dur i ng eval uat i on,
yi el di ng i ncor r ect r esul t s. */
t hi snum38 : = 186282 * 60 * 60 * 24 * 365. 25;
RAI SE NOTI CE ' t hi snum38 == %' , t hi snum38;
END;
END_PROC;
Sample output follows:
NOTI CE: t hi snum9_2 == 4945731. 93
NOTI CE: t hi snum9_2 == 4952164. 15
NOTI CE: t hi snum18 == 5878612843200
NOTI CE: t hi snum38 == - 396334376256
As this example shows, explicit casts during arithmetic evaluations and careful use of liter-
als, constants, and types can help to increase the accuracy of the expressions used in your
stored procedures.
Statements
The following sections describe the types of statements which are explicitly understood by
the NZPLSQL parser. Any statements which are not specified using these conventions (and
thus are not understood by the NZPLSQL parser) are assumed to be SQL commands and
sent to the database engine to execute. The resulting query should not return any data.
Assignment
To assign a value to a variable or row/record field, use the assignment statement as follows:
identifier : = expression;
If the expressions result data type does not match the variables data type but the types are
compatible, or the variable has a size/precision that is known (as for char(20)), the result
value will be implicitly cast by the NZPLSQL bytecode interpreter using the result types
output-function and the variables type input-function. Note that this could potentially
result in runtime errors generated by the types input functions.
Several examples follow:
user _i d : = 20;
t ax : = subt ot al * 0. 06;
For more information about Netezza casting rules and behaviors, see the Netezza Database
Users Guide.
Calling Another Procedure
All procedures defined in a Netezza database return a value; the default value is NULL.
Thus, the normal way to call a procedure is to execute a SELECT query or to do an assign-
ment (resulting in an NZPLSQL internal SELECT).
However, there are cases where you might not be concerned with the procedure's result. In
these cases, use the CALL statement to call the procedure, as follows:
CALL quer y
The CALL statement executes a SELECT query and discards the result. Identifiers such as
local variables are still substituted into input parameters.
20470-02 Rev. 1 2-15
Statements
There is a maximum stored procedure call recursion limit of 1024. If the call recursion
exceeds this value, the following error message is returned:
ERROR: st or ed pr ocedur e r ecur si on l i mi t exceeded
Executing Dynamic Queries
There may be times when you want to generate dynamic queries inside your NZPLSQL pro-
cedures. Or, you may have procedures that are designed to generate other procedures. For
these situations, NZPLSQL provides the EXECUTE IMMEDIATE statement:
EXECUTE I MMEDI ATE query-string
The query-string value is a string of type text which contains the query to be executed.
When working with dynamic queries, make sure that you escape any single quotes in
NZPLSQL.
A query run by an EXECUTE IMMEDIATE statement is prepared each time the statement is
run. The query string can be dynamically created within the procedure to perform actions
on different tables and fields.
The results from SELECT queries are discarded by EXECUTE IMMEDIATE, and SELECT
INTO is not currently supported within EXECUTE IMMEDIATE. So, the only way to extract a
result from a dynamically-created SELECT is to use the FOR ... EXECUTE form, described
in Iterating Through Records on page 2-20.
An example statement follows:
EXECUTE I MMEDI ATE ' UPDATE t bl SET'
| | quot e_i dent ( ' f i el dname' )
| | ' = '
| | quot e_l i t er al ( ' newval ue' )
| | ' WHERE . . . ' ;
This example demonstrates the use of the quote_ident and quote_literal functions. To
ensure that strings are correctly processed for quotes or special characters, expressions
containing column and table identifiers should be passed to quote_ident. Expressions con-
taining values that should be literal strings in the constructed command should be passed
to quote_literal. Both take the appropriate steps to return the input text enclosed in double
or single quotes, respectively, with any embedded special characters properly escaped.
Obtaining Other Results Status
There are two variables that provide system status indicators: ROW_COUNT and LAST_OID.
ROW_COUNT is the number of rows processed by the last SQL query sent down to the
SQL engine.
LAST_OID is the object ID (oid) of the last row inserted by the most recent SQL query.
LAST_OID is useful only after an INSERT query, and then only when the insert happens on
a catalog table. In practice, LAST_OID is not likely to be very useful.
In addition to these variables, you can also use the FOUND and IS NULL variables to per-
form special conditional processing based on record results. For more information, see
Assignments on page 2-19.
2-16 20470-02 Rev. 1
Returning From a Procedure
The RETURN command allows you to return data from a procedure:
RETURN [ expression]
The procedure terminates and the value of expression is returned to the upper executor. If
expression is not provided, NULL is assumed.
The return value of a procedure can be undefined. If control reaches the end of the top-
level block of the procedure without encountering a RETURN statement, NULL is assumed.
The expressions result is automatically cast into the procedure's return type as described
for assignments.
Control Structures
Control structures may be the most useful and important part of the NZPLSQL language.
With NZPLSQL's control structures, you can manipulate SQL data in a very flexible and
powerful way.
Conditional Control
You use IF statements to take action according to certain conditions. NZPLSQL has three
forms of IF statements:
IF-THEN
IF-THEN-ELSE
IF-THEN-ELSE IF
Note: All NZPLSQL IF statements require a corresponding END IF statement. In ELSE-IF
statements, you need two END IF statements: one for the first IF and one for the second
(ELSE IF).
IF-THEN Statements
IF-THEN statements are the simplest form of an IF. The statements between THEN and
END IF will be executed if the condition is true. Otherwise, the statements following END
IF will be executed. An example follows:
I F v_user _i d <> 0 THEN
UPDATE user s SET emai l = v_emai l WHERE user _i d = v_user _i d;
END I F;
IF-THEN-ELSE Statements
IF-THEN-ELSE statements add to IF-THEN by letting you specify the statements that
should be executed if the condition evaluates to FALSE. For example:
I F par ent i d I S NULL or par ent i d = ' '
THEN
r et ur n f ul l name;
ELSE
r et ur n hp_t r ue_f i l ename( par ent i d) | | ' / ' | | f ul l name;
END I F;
I F v_count > 0 THEN
I NSERT I NTO user s_count ( count ) VALUES( v_count ) ;
20470-02 Rev. 1 2-17
Control Structures
r et ur n ' t ' ;
ELSE
r et ur n ' f ' ;
END I F;
You can nest IF statements as in the following example:
I F movi es. genr e = ' d' THEN
f i l m_genr e : = ' dr ama' ;
ELSE
I F movi es. genr e = ' c' THEN
f i l m_genr e : = ' comedy' ;
END I F;
END I F;
IF-THEN-ELSE IF Statement
When you use the "ELSE IF" statement, you are actually nesting an IF statement inside the
ELSE statement. Thus you need one END IF statement for each nested IF and one for the
parent IF-ELSE. For example:
ELSE I F movi es. genr e = ' c' THEN
END I F;
END I F;
While this form works, it can become a little tedious and error-prone if there are many alter-
natives to check. Thus, the language offers the alternative syntax using ELSIF or ELSEIF,
as follows:
ELSI F movi es. genr e = ' c' THEN
ELSI F movi es. genr e = ' a' THEN
f i l m_genr e : = ' act i on' ;
ELSI F movi es. genr e = ' n' THEN
f i l m_genr e : = ' nar r at i ve' ;
ELSE
- - An uncat egor i zed genr e f or mhas been r equest ed.
f i l m_genr e : = ' Uncat egor i zed' ;
END I F;
The IF-THEN-ELSIF-ELSE form offers some flexibility and eases the coding process when
you need to check many alternatives in one statement. While it is equivalent to nested IF-
THEN-ELSE-IF-THEN commands, it needs only one END IF statement.
Iterative Control
With the LOOP, WHILE, FOR, and EXIT statements, you can control the flow of execution of
your NZPLSQL program iteratively.
Loop Statement
The LOOP statement defines an unconditional loop that repeats until terminated by an
EXIT statement or a RETURN statement (which terminates the procedure and the loop). It
has the following syntax:
2-18 20470-02 Rev. 1
[ <<label>>]
LOOP
statements
END LOOP;
The optional label can be used by EXIT statements of nested loops to specify which level of
nesting should be terminated.
EXIT Statement
The EXIT statement terminates a loop. It has the following syntax:
EXI T [ label ] [ WHEN expression ] ;
If you do not specify a label, the innermost loop is terminated and the statement following
END LOOP is executed next. If you specify a label, it must be the label of the current or an
upper level of nested loop or blocks. Then the named loop or block is terminated and con-
trol continues with the statement after the loops/blocks corresponding END.
Examples:
LOOP
- - some comput at i ons
I F count > 0 THEN
EXI T; - - exi t l oop
END I F;
END LOOP;
LOOP
EXI T WHEN count > 0;
END LOOP;
BEGI N
I F st ocks > 100000 THEN
EXI T;
END I F;
END;
WHILE Statement
With the WHILE statement, you can loop through a sequence of statements as long as the
evaluation of the condition expression is true.
[ <<l abel >>]
WHI LE expression LOOP
statements
END LOOP;
For example:
WHI LE amount _owed > 0 AND gi f t _cer t i f i cat e_bal ance > 0 LOOP
- - some comput at i ons her e
END LOOP;
WHI LE NOT bool ean_expr essi on LOOP
- - some comput at i ons her e
END LOOP;
20470-02 Rev. 1 2-19
FOR Statement
Using the FOR statement, you can create a loop that iterates over a range of integer values.
[ <<l abel >>]
FOR name I N [ REVERSE ] expr essi on . . expr essi on LOOP
st at ement s
END LOOP;
The variable name is automatically created as type integer and exists only inside the loop.
The two expressions for the lower and upper bound of the range are evaluated only when
entering the loop. The iteration step is always 1.
Some examples of FOR loops:
FOR i I N 1. . 10 LOOP
- - some expr essi ons her e
RAI SE NOTI CE ' i i s %' , i ;
END LOOP;
FOR i I N REVERSE 1. . 10 LOOP
- - some expr essi ons her e
END LOOP;
Records are similar to rowtypes, but they have no predefined structure. They are used in
selections and FOR loops to hold one database row from a SELECT operation.
Declaration
Variables of type RECORD can be used for different selections. Accessing a record or an
attempt to assign a value to a record field when there is no row in it results in a run-time
error. To declare a RECORD variable:
name RECORD;
Assignments
You can use the following query to assign a complete selection into a record or row:
SELECT expressions I NTO target FROM . . . ;
target can be a record, a row variable, or a comma-separated list of variables and record-
fields or row-fields. Note that this is different from the SQL interpretation of SELECT INTO,
which is that the INTO target is a newly created table. (If you want to create a table from a
SELECT result inside a NZPLSQL procedure, use the equivalent syntax CREATE TABLE AS
SELECT.)
If a row or a variable list is used as the target, the selected values must exactly match the
structure of the target(s) or a runtime error occurs. The FROM keyword can be followed by
any valid qualification, grouping, or sorting that can be given for a SELECT statement.
After a record or row has been assigned to a RECORD variable, you can use the "." (dot)
notation to access fields in that record as follows:
DECLARE
user s_r ec RECORD;
f ul l _name var char ;
2-20 20470-02 Rev. 1
BEGI N
SELECT * I NTO user s_r ec FROM user s WHERE user _i d=3;
f ul l _name : = user s_r ec. f i r st _name | | ' ' | | user s_r ec. l ast _name;
There is a special variable named FOUND of type boolean that can be used immediately
after a SELECT INTO to check whether an assignment was successful. The following exam-
ple uses the NOT FOUND form to raise an exception if a SELECT INTO statement does not
match on the requested input name:
SELECT * I NTO myr ec FROM EMP WHERE empname = myname;
I F NOT FOUND THEN
RAI SE EXCEPTI ON ' empl oyee %not f ound' , myname;
END I F;
FOUND is very similar to ROW_COUNT (described in Obtaining Other Results Status on
page 2-15). For example, the following statement:
I F FOUND
is equivalent to this statement:
I F ROW_COUNT >= 1
You can also use the IS NULL (or ISNULL) conditionals to test whether a RECORD or ROW
is NULL. If the selection returns multiple rows, only the first is moved into the target fields.
All others are silently discarded. For example:
DECLARE
user s_r ec RECORD;
f ul l _name var char ;
BEGI N
SELECT * I NTO user s_r ec FROM user s WHERE user _i d=3;
I F user s_r ec. homepage I S NULL THEN
- - user ent er ed no homepage, r et ur n " ht t p: / / "
r et ur n ' ht t p: / / ' ;
END I F;
END;
Iterating Through Records
Using a special type of FOR loop, you can iterate through the results of a query and manip-
ulate that data accordingly. The FOR IN loop syntax is as follows:
[ <<l abel >>]
FOR record | row I N select_clause LOOP
statements
END LOOP;
The record or row is assigned all the rows resulting from the select clause and the loop body
is executed for each. An example follows:
DECLARE
mvi ews RECORD;
- - I nst ead, i f you di d:
- - mvi ews cs_mat er i al i zed_vi ews%ROWTYPE;
- - t hi s r ecor d i s ONLY usabl e f or t he cs_mat er i al i zed_vi ews t abl e
BEGI N
CALL cs_l og( ' Ref r eshi ng mat er i al i zed vi ews. . . ' ) ;
FOR mvi ews I N SELECT * FROM cs_mat er i al i zed_vi ews ORDER BY sor t _key LOOP
- - Now " mvi ews" has one r ecor d f r omcs_mat er i al i zed_vi ews
RAI SE EXCEPTI ON, ' Can' t execut e SQL whi l e pr ocessi ng SQL f or %' ,
mvi ew. my_name;
20470-02 Rev. 1 2-21
END LOOP;
CALL cs_l og( ' Done r ef r eshi ng mat er i al i zed vi ews. ' ) ;
r et ur n 1;
end;
If the loop is terminated with an EXIT statement, the last assigned row is still accessible
after the loop.
The FOR-IN EXECUTE statement is another way to iterate over records:
[ <<l abel >>]
FOR record | row I N EXECUTE text_expression LOOP
statements
END LOOP;
This is similar to the previous form, except that the source SELECT statement is specified
as a string expression. The main difference between the two is the syntax and use of vari-
ables to build the SQL to execute. Note that the first form is faster to evaluate.
Use the RAISE statement to report messages and raise errors. The statement syntax
follows:
RAI SE level ' format' [ , identifier [ . . . ] ] ;
Inside format, the percent character (%) is used as a placeholder for a subsequent,
comma-separated identifier. You can specify more than one % and identifier pair, as
follows:
RAI SE NOTI CE ' Wel come %%' , f i r st name, l ast name;
In this example, the notice message substitutes the value of firstname for the first % char-
acter, and substitutes the value of lastname for the second % character.
The message levels are as follows:
DEBUG messages only appear in pg.log.
NOTICE messages are written to the database log and forwarded to the client
application.
EXCEPTION messages are written to the database log, forwarded to the client applica-
tion as non-fatal messages, and usually abort the transaction if they are not caught.
An example of a RAISE statement follows:
RAI SE NOTI CE ' Cal l i ng cs_cr eat e_j ob( %) ' , j ob_i d;
In the example, job_id will replace the % in the string and display the message to the client
and in pg.log.
RAI SE EXCEPTI ON ' I nexi st ent I D - - > %' , user _i d;
This EXCEPTION statement will abort the transaction (if the exception is not caught) and
write the message to the database log.
2-22 20470-02 Rev. 1
Exceptions and Error Messages Support
By default, any error occurring in a NZPLSQL procedure aborts the execution of the proce-
dure, and aborts the surrounding transaction as well. The system returns to the main loop
to obtain the next query from the client application. Note that it is not possible to catch all
exceptions, especially if that action should leave the database in a bad state.
The NZPLSQL language uses the EXCEPTION statement to process exceptions:
EXCEPTI ON WHEN OTHERS THEN
Handler_statements
You place the statement at the end of a block. If no error occurs, the EXCEPTION handler
statements are not executed.
The variable SQLERRM contains the text of an error message that has been caught. In the
absence of an exception block, the exception propagates up to the next stored procedure in
the call stack. So, for example, if sproc1 calls sproc2 which generates an exception, but
sproc2 does not have an exception handler, then the system looks for a handler in sproc1.
The system also looks at the enclosing block declarations.
For example:
cr eat e or r epl ace pr ocedur e sp_except 01( ) r et ur ns BOOL LANGUAGE
NZPLSQL AS
BEGI N_PROC
DECLARE
r r ecor d;
BEGI N
<<i nner >>
BEGI N
SELECT * I NTO r FROM NONEXI STENT;
END;
END;
END_PROC;
NZPLSQL AS
BEGI N_PROC
BEGI N
CALL sp_except 01( ) ;
END;
END_PROC;
NZPLSQL AS
BEGI N_PROC
BEGI N
CALL sp_except 02( ) ;
RAI SE NOTI CE ' Caught except i on' ;
END;
END_PROC;
In these examples, the exception is generated in sp_except01, in the block inner. The sys-
tem first checks for an exception handler for block inner, which is not found. Control passes
to the parent context, which is the procedure sp_except01, and an exception handler is
also not found there. Control then passes to sp_except02, and finally sp_except03, where
an exception handler is found and used.
20470-02 Rev. 1 2-23
If an exception is not caught at any level, additional NOTICE-level log messages are sent to
provide context about the error and where it occurred (line number and type of statement,
unless the error is from a RAISE EXCEPTION statement).
If you include exception handlers in stored procedures, the handlers will catch any errors
and the errors are not displayed. For example:
CREATE PROCEDURE sp( ) RETURNS I NTEGER LANGUAGE NZPLSQL AS
BEGI N_PROC
BEGI N
EXECUTE I MMEDI ATE ' i nser t i nt o NOTEXI ST' | | ' val ues( 1, 1) ' ;
END;
END_PROC;
Assuming that NOTEXIST does not exist in the database, the query does not display any
error output because the error was handled by the exception handler.
To display the error, write the procedure as follows:
CREATE PROCEDURE sp( ) RETURNS I NTEGER LANGUAGE NZPLSQL AS
BEGI N_PROC
BEGI N
EXECUTE I MMEDI ATE ' i nser t i nt o NOTEXI ST' | | ' val ues( 1, 1) ' ;
RAI SE NOTI CE ' Got except i on: %' , SQLERRM;
END;
END_PROC;
When you run this query, it displays the following output:
NOTI CE: Got except i on: ERROR: Rel at i on ' NOTEXI ST' does not exi st
Typically, an NZPLSQL procedure returns a unique return value, but it can also return a
result set in the form of a specified table.
To create a stored procedure that returns a result set, do the following:
Define the stored procedure with a return value of RETURNS REFTABLE (<table-
name>) to indicate that it returns a result set that looks like the specified table.
Inside the body of the procedure, use the variable REFTABLENAME to refer to the
results table.
The table specified in the RETURNS value must exist at the time that the stored procedure
is created, although the table could be empty. The table will continue to exist after the
stored procedure completes. You will not be permitted to drop the reference table while the
stored procedure is defined. (That is, you must drop the stored procedure or modify it to
return a different reference table before you can drop the table.)
For example, the following stored procedure returntwo returns a result set using the refer-
ence table feature. The reference table that it uses, tbl, was previously defined using the
following command:
CREATE TABLE t bl ( i I NT4, i 2 I NT4) ;
2-24 20470-02 Rev. 1
A description of tbl follows:
DEV( ADMI N) => \d tbl
Tabl e " TBL"
- - - - - - - - - - - +- - - - - - - - - +- - - - - - - - - - +- - - - - - - - - - - - - - -
I | I NTEGER | |
I 2 | BI GI NT | |
Di st r i but ed on hash: " I "
After you confirm that the reference table exists, you can use the following command to
define the stored procedure returntwo:
DEV( ADMI N) => CREATE OR REPLACE PROCEDURE returntwo(timestamp) RETURNS
REFTABLE(tbl) LANGUAGE NZPLSQL AS
BEGIN_PROC
BEGIN
EXECUTE IMMEDIATE 'INSERT INTO ' || REFTABLENAME ||' values (1,1)';
EXECUTE IMMEDIATE 'INSERT INTO ' || REFTABLENAME ||' values (2,2)';
RETURN REFTABLE;
END;
END_PROC;
A sample call to the returntwo stored procedure follows:
DEV( ADMI N) => EXECUTE PROCEDURE returntwo(now());
I | I 2
- - - +- - - -
1 | 1
2 | 2
( 2 r ows)
Note: You cannot specify a WHERE clause in a query which calls a stored procedure that
returns a result set.
When you call or invoke the stored procedure using a SQL command such as SELECT pro-
cedure(), CALL procedure(), EXECUTE procedure(), and so forth, the database does the
following:
Generates a tablename TEMPFUNC<oid> where oid is the object ID of the procedure
that was invoked
Checks if the tablename exists; if it does, it issues a DROP TABLE <temp-table-name>
command
Issues a CREATE TEMPORARY TABLE <temp-table-name> as select * from <table-
name> LIMIT 0 to create the table for the results set with no initial contents
Returns the results of SELECT * from <temp-table-name> where proc(args) is NULL
(Note that this is the only situation in which a stored procedure is allowed to be exe-
cuted with a FROM clause and where the return value is used as part of a query.)
To use this in a procedure, you must insert your results in <temp-table-name> using the
REFTABLENAME variable to obtain the name. This SQL command must be invoked dynam-
ically in order to use the variable.
Additionally, you must return NULL in your procedure by one of the following means:
RETURN REFTABLE;
RETURN NULL;
20470-02 Rev. 1 2-25
RETURN;
Not specifying a RETURN clause.
If you do not return NULL, the procedure returns an error. The recommended method to
return NULL is RETURN REFTABLE.
One REFTABLE procedure can call another, but you will encounter unusual results if a
REFTABLE procedure calls itself (either directly or recursively) because of the temporary
table logic; therefore, avoid designing a REFTABLE procedure which calls itself.
Cross-database access for a REFTABLE procedure should work without problem as the tem-
porary table will be created in the local database; it will retrieve the shape of the
REFTABLE definition in the other database.
The SQL that is executed (for example, CREATE TEMPORARY TABLE, DROP TABLE, and
so forth) uses the owner ID of the procedure as the effective user ID if EXECUTE AS
OWNER is set; otherwise, if EXECUTE AS CALLER is set, the SQL uses the user ID of the
account which calls or invokes the procedure.
Managing Large Datasets
If users run stored procedures on large datasets, there may be situations where there is not
enough memory to hold the results of a select on that table. For example, some stored pro-
cedures could read each record from a table and take action on each record, as follows:
FOR r ec i n SELECT * f r omt abl enmLOOP
- - per f or mpr ocessi ng st eps
END LOOP:
The SELECT operation runs first and caches its results in memory or as a temporary file on
disk, depending upon the size of the result set. The procedure then applies the steps in the
inner processing loop.
If the table (tablenm) is very large, such as a table with millions of rows or one with many
thousands of large rows, the temporary file could be a huge file which consumes the free
disk space on the Netezza host. Use caution when your stored procedures process very
large tables.
Note: In the Netezza environment, these types of select loops that operate on single rows
are not optimized for performance in the Netezza environment. Where possible, recast the
loop to operate on record sets. For more information, see Query Processing in Loops on
page 2-26.
The following sections describe some topics which leverage user-defined functions and
stored procedures to perform advanced programming and scripting on the Netezza system.
Extending the Language with UDFs
If you or other users at your site create user-defined functions (UDFs) for your Netezza sys-
tems, you can use UDFs to extend the NZPLSQL language. These UDFs must be invoked
using SQL that is designed to run only on the Netezza host inside Postgres. For details
2-26 20470-02 Rev. 1
about the use of UDFs to extend NZPLSQL, refer to the Netezza User-Defined Functions
Developers Guide. Note that the guide is available only to members of the Netezza Devel-
oper Network (NDN); contact ndnsupport@netezza.com for more information.
Tips and Developer Best Practices
The following sections describe some common tips and best practices for stored
procedures.
Control-C Interrupt Processing in Loops
If the procedure encounters an infinite loop, you can press Control-C to interrupt the loop.
This key sequence should cause an exception (which is not catchable) and thus cause the
loop and the procedure call to be interrupted and return.
Query Processing in Loops
Within stored procedures, there may be loop designs which appear to use concurrent que-
ries to process the results. For example, the following procedure uses a SELECT to gather
information, which is then processed for a possible DELETE action:
FOR r ec i n SELECT * f r ommyt abl e LOOP
I F r ec. t ype = d THEN
EXECUTE I MMEDI ATE DELETE FROM myt abl e2 WHERE r eci d = | | r ec. i d;
END I F;
END LOOP;
While it appears that the outer FOR loop SELECT and the inner EXECUTE IMMEDIATE
queries are running at the same time, the SELECT query finishes and caches its results
before the inner query begins. Thus, deleting records from the table in the inner loop will
not impact the SELECT query in the outer loop or change its results.
Note: Although it may be very common to perform row-at-a-time operations, as used in the
preceding example, you can significantly improve the performace of these procedures by
designing them to operate on sets of records rather than single row operations. For exam-
ple, if you recast the example above to the following:
DELETE f r om myt abl e2 wher e r eci d i n ( sel ect r eci d f r om my t abl e
wher e t ype = ' d' ) ;
This procedure design can take advantage of Netezzas massively parallel processing (MPP)
environment to run much more quickly.
3-1
C H A P T E R 3
Creating and Managing Stored Procedures
Managing User Account Permissions
Creating a Stored Procedure
Calling or Invoking a Stored Procedure
Altering a Stored Procedure
Commenting on a Stored Procedure
Dropping a Stored Procedure
Showing Information About a Stored Procedure
NzAdmin UI for Stored Procedures
This chapter describes the basic management and user tasks associated with stored proce-
dures, such as managing permissions, creating procedures, invoking procedures, and
altering and dropping stored procedures.
Managing User Account Permissions
Before you create any stored procedures, familiarize yourself with the required account per-
missions necessary to create and manage these objects. The Netezza admin user has full
permission to manage and execute stored procedures. The database owner also has full
permission to objects within the database that he or she owns. In addition, the owner (that
is, the user who created the stored procedure) has permission to manage and execute the
stored procedures that he or she creates.
As the admin user or any user who has account management permissions, you can grant
other users permission to create, manage, or execute the stored procedures on a Netezza
system. You can assign permissions using the NzAdmin user interface, or by using the
GRANT and REVOKE SQL commands. For details on managing users and groups, as well as
assigning permissions using the NzAdmin interface, refer to the Netezza System Adminis-
trators Guide.
If you use SQL commands to manage account permissions, note some special formats and
syntax for the commands. In the following examples, the term entity represents either a
user or a user group. The term object represents the word PROCEDURE (for all stored pro-
cedure objects) or a specific stored procedure if object is specified as a full signature with
the procedure name and argument type list.
3-2 20470-02 Rev. 1
Make sure that you specify the correct signature including the sizes for numeric and string
datatypes, otherwise you will receive an error similar to the following:
ERROR: Gr ant RevokeCommand: exi st i ng UDX NAME( ARGS) di f f er s i n si ze of
st r i ng/ numer i c ar gument s
Granting Create Permission
To grant Create Procedure administration permissions:
GRANT CREATE PROCEDURE TO entity;
For example, the following command grants Create Procedure permissions to the user
bsmith:
GRANT CREATE PROCEDURE TO bsmith;
Granting All Object Permissions
To grant users or a group with all object permissions, use the following command:
GRANT ALL ON PROCEDURE TO entity;
This command gives the user or group the Alter, Drop, List, and Execute privileges for pro-
cedures, as well as other permissions such as Insert, Delete, and others which are not used
for procedures.
For example, the following command grants object permissions to the user bsmith:
GRANT ALL ON PROCEDURE TO bsmith;
Revoking Create Permission
To revoke Create Procedure administration permission:
REVOKE CREATE PROCEDURE FROM entity;
For example, the following command revokes Create Procedure permissions from the group
analysts:
REVOKE CREATE PROCEDURE FROM GROUP analysts;
Managing Alter Permission
To grant or revoke Alter permission on an object:
GRANT ALTER ON object TO entity;
REVOKE ALTER ON object FROM entity;
For example, to grant Alter permissions for the sample stored procedure returntwo to the
user asmith:
GRANT ALTER ON returntwo(timestamp) TO asmith;
To revoke Alter permissions on the returntwo procedure from the group sales:
REVOKE ALTER ON returntwo(timestamp) FROM GROUP sales;
Managing Execute Permission
To grant or revoke Execute permission on an object:
GRANT EXECUTE ON object TO entity;
20470-02 Rev. 1 3-3
For example, to grant Execute permissions for the sample procedure returntwo to the user
bsmith, you can use the following command:
GRANT EXECUTE ON returntwo(timestamp) TO bsmith;
To revoke Execute permissions for the sample procedure from the group sales:
REVOKE EXECUTE ON returntwo(timestamp) FROM GROUP sales;
Managing Drop Permission
To grant or revoke Drop permissions on an object:
GRANT DROP ON object TO entity;
REVOKE DROP ON object FROM entity;
For example, to grant Drop permissions for the sample procedure returntwo to the user
pcollins:
GRANT DROP ON returntwo(timestamp) TO pcollins;
To revoke Drop permissions on the returntwo procedure from the user bsmith:
REVOKE DROP ON returntwo(timestamp) FROM bsmith;
The process to create a stored procedure is very straightforward; typically, the time-con-
suming work is in the design of the stored procedure, as well as the debugging and testing
of the procedure. This section describes the following key steps for creating a stored
procedure:
Design a stored procedure
Create a stored procedure
Design a Stored Procedure
The first step is to design the procedure itself. Make sure that you outline the basic pur-
pose and actions of the procedure, consider helpful error logging, and plan for exception
handling. Review the NZPLSQL language and statements to create the body of the
procedure.
Create a Stored Procedure
After you have created the body of the stored procedure, you add it using the CREATE [OR
REPLACE] PROCEDURE command. You enter this command at a SQL command prompt.
The CREATE PROCEDURE command creates a new procedure. To use this command, you
must be the admin user, own the database, or have the Create Procedure privilege. The
CREATE OR REPLACE PROCEDURE command will create a new procedure if one does not
already exist with the specified signature, or will update an existing procedure with the
matching signature for the new (or different) field values. To replace a procedure, you must
have the Alter privilege.
3-4 20470-02 Rev. 1
For example, the following procedure customer writes a customer name string to the
database log using the RAISE NOTICE statement:
TEST( USR) => CREATE PROCEDURE customer()
RETURNS INT4 LANGUAGE NZPLSQL AS
BEGIN_PROC
BEGIN
RAISE NOTICE 'The customer name is alpha';
END;
END_PROC;
CREATE PROCEDURE
Since the execution user permissions were not specified on the command line, the com-
mand uses the default of EXECUTE AS OWNER.
If you want to change the customer procedure to specify a new return value, you could use
a CREATE OR REPLACE PROCEDURE command similar to the following, but note that you
must specify all the required fields (such as language and the complete procedure body)
even if their values did not change, as follows:
TEST( USR) => CREATE OR REPLACE PROCEDURE customer()
BEGIN_PROC
BEGIN
END;
END_PROC;
CREATE PROCEDURE
You can also use the ALTER PROCEDURE command to modify certain characteristics of a
defined procedure, as described in Altering a Stored Procedure on page 3-10.
Procedure Signatures
Each stored procedure has a signature; that is, a unique identification in the form
<procedure_name>(<argument_type_list>). Signatures must be unique within the same
database; that is, they cannot duplicate the signature of another stored procedure. The
<argument_type_list> component does not consider data type sizes to be differentiators.
For example, you cannot create two procedures called myproc(numeric(3,2)) and
myproc(numeric(4,1)) in the same database. The larger numeric size is not sufficient to
create a unique signature.
If there are common use-cases where a procedure must accept different sized strings or
numerics, you could design the procedure to accept the largest of the possible values, or
you could create a new stored procedure with a different name to process the different data
size, for example:
TEST( USR) => CREATE PROCEDURE myproc_lgnum(numeric(4,1))
...
Overloading Procedures
You can create stored procedures that have the same procedure name, but which have dif-
ferent argument signatures and return types. This process is referred to as overloading the
procedure definition. For example, assume that you have a procedure called
customer_name that could take two or three input strings which represent a customers
first, middle (if specified), and last name.
20470-02 Rev. 1 3-5
Some sample procedure definitions follow:
TEST( USR) => CREATE PROCEDURE customer_name(VARCHAR(30), VARCHAR(30))
...
TEST( USR) => CREATE PROCEDURE customer_name(VARCHAR(30), VARCHAR(30),
VARCHAR(30))
...
If a user calls customer_name with two input strings, the system uses the first (two argu-
ment) procedure. If the user specifies three input strings, the procedure uses the second
procedure that accepts three input strings.
Overloading allows you to support different combinations of input values and/or return
types. However, overloading and uniquely named but similar procedures have a mainte-
nance overhead; if you need to update or redesign the body of the procedure, you have to
update each procedure definition with the changes that you want to make.
Understanding Size-Specific, Generic, and Variable Argument Procedures
In the signature of a stored procedure, the <argument_type_list> can use three general
forms:
Size-specific arguments
Generic arguments
Variable arguments
The following sections describe these three formats and the benefits and considerations for
using that type.
Size-Specific Arguments
With size-specific arguments, you declare the type and size of all input arguments, as well
as the type and size of the return value. Specific datatype size declarations are useful for
error-checking of the input arguments and return values, but they can be somewhat limiting
if your procedure processes strings or numerics which could vary in size when you run a
query.
For example, the following example creates a stored procedure that takes a string of up to
20 VARCHAR characters:
TEST( USR) => CREATE PROCEDURE customer(VARCHAR(20))
BEGIN_PROC
BEGIN
remaining text omitted for example...
Constant datatype sizes can result in implicit casts, such as casting a smaller input value
to fit a larger declared size (for example, it could increase the precision of a numeric or add
padding to strings). If you choose too small a size, you risk loss of precision if Netezza casts
a larger input numeric to a smaller numeric or truncates input strings that exceed the input
argument size.
Generic-Size Arguments
Generic-size (or any-size) arguments offer more flexibility for strings and numerics. You can
declare character strings or numerics using the ANY keyword in the signature (or in the
return value). For example:
3-6 20470-02 Rev. 1
TEST( USR) => CREATE PROCEDURE customer(VARCHAR(ANY))
RETURNS VARCHAR(ANY) LANGUAGE NZPLSQL AS
BEGIN_PROC
BEGIN
The stored procedure accepts an input string of up to 64,000 characters (the maximum for
a VARCHAR). Within the body of the stored procedure, the code must process the strings
and numerics with the plan that you could receive a string of any valid length. That is, you
can check and obtain their size, process them as needed, and return the value for the
procedure.
Generic-size arguments help you to avoid specific limits for the input strings and numerics,
or to use overly large or maximum size values that result in unnecessary resource allocation
for the procedure. This format can also reduce the need to register and maintain similar
procedures that take different input arguments or have different return values, as well as
possible casting of input values.
Supported Generic Argument Types You use the ANY keyword to indicate that an argument
is generic. The following datatypes support the ANY keyword as a size specifier:
CHAR or NCHAR
VARCHAR or NVARCHAR
NUMERIC
For example, to specify a numeric datatype of precision 10 and scale 2, you specify it as
NUMERIC(10,2). To specify a numeric datatype that can take any size, you specify is as
NUMERIC(ANY). Likewise, to specify a variable character string that can take any size, you
declare it as VARCHAR(ANY).
Generic Arguments in the Procedure Signature You can define generic arguments as well as
the standard datatype-and-size-specific arguments in the signature of a stored procedure.
The Netezza software verifies that all the input arguments match the required number and
datatypes of the signature.
For arguments that have a specific size, the Netezza software also confirms that the size of
the input value matches the defined signature size. If necessary, the Netezza software casts
the input values to match the size specified in the signature. For example, if you declare a
string of 20 characters [CHAR(20)] in a signature, the Netezza software implicitly trun-
cates an input string that is longer than 20 characters or adds padding if the input string is
less than 20 characters.
For generic arguments, the argument values are passed to the procedure without any cast-
ing or changes. For example, if you declare a CHAR(ANY) input value, the procedure
accepts character strings of any length up to the supported maximum; it checks to make
sure that the input value is a valid character string and that it occurs in the expected place
of the signature.
The Netezza software performs some implicit castings for the input values. For example, if
you define an input argument as VARCHAR(ANY) in the signature, but you pass an input of
CHAR(200) to the procedure, the procedure casts the CHAR(200) to VARCHAR(200). The
procedure uses the datatype of the signature and the size of the input value to determine
the casting change.
20470-02 Rev. 1 3-7
Generic Procedure Return Value If you use ANY for a return value size, your procedure cal-
culates the size of the numeric or string return value from the RETURN expression and
simply returns it.
Registering Generic Procedures When you register a stored procedure that uses generic
arguments, you use the keyword ANY to declare character or numeric datatypes as generic.
For a complete description of the command, refer to CREATE [OR REPLACE] PROCE-
DURE on page A-6.
An example follows:
MYDB( USR) => CREATE PROCEDURE itemfind(NUMERIC(ANY))
RETURNS CHAR(ANY) LANGUAGE NZPLSQL AS
BEGIN_PROC
BEGIN
/* Body of procedure... intentionally omitted from example*/
END;
END_PROC;
In this example, the itemfind() procedure takes an input numeric datatype of any valid size
and returns char value of any size.
Variable Arguments
Variable-argument procedures offer even more flexibility than generic-size arguments. With
variable argument procedures, you specify only the VARARGS keyword in the
argument_type_list. Users can specify from 0 to 64 input values of any supported data type
as input arguments. For example:
TEST( USR) => CREATE PROCEDURE customer(VARARGS)
RETURNS VARCHAR(ANY) LANGUAGE NZPLSQL AS
BEGIN_PROC
BEGIN
Within the body of the stored procedure, the code must process the input values and man-
age them as needed. For more information, see Argument List and Variables on
page 2-4.
Variable argument procedures allow you to create one procedure that can be used for differ-
ent combinations of input types. This simplifies the development of stored procedures and
reduces the need to create overloaded procedure definitions that perform the same task for
different types and numbers of arguments.
Obfuscating the Procedure Body
As shown in CREATE PROCEDURE examples, the procedure body is entered in readable
text format. Users who have permission to show the procedure can use the VERBOSE
option to review the procedure body (see Showing Information About a Stored Procedure
on page 3-12). If your procedure body contains intellectual property, copyrighted material,
or other algorithms that you do not want in clear text, you can obfuscate the body text.
3-8 20470-02 Rev. 1
Creating Obfuscated Procedures Using a Wrapping Procedure
A common way to create an obfuscated stored procedure is by creating a stored procedure
wrapper that takes the procedure definition and the procedure body, and creates the
obfuscated procedure, as in the following example:
TEST( USR) => CREATE OR REPLACE PROCEDURE wrap_proc(text, text)
RETURNS BOOL LANGUAGE NZPLSQL AS
BEGIN_PROC
DECLARE
proc alias for $1;
body alias for $2;
enc text;
sql text;
BEGIN
enc := wrap_nzplsql(body);
sql := proc || '' || '' || quote_literal(enc) || '';
RAISE NOTICE '%;', sql;
EXECUTE IMMEDIATE sql;
return true;
END;
END_PROC;
CREATE PROCEDURE
Call the wrap_proc procedure and specify the CREATE OR REPLACE main definition in the
first input value; then specify the BEGIN PROC/END PROC contents in the second input
value. You must surround the main definition (the first input value) with single quotes. Do
not enclose the second input value (the procedure body) in quotes because the
wrap_nzplsql built-in procedure takes the text just as it would be specified for a CREATE
OR REPLACE PROCEDURE command. An example follows:
TEST( USR) => CALL wrap_proc('CREATE OR REPLACE PROCEDURE customer()
RETURNS INT4 LANGUAGE NZPLSQL AS',
BEGIN_PROC
BEGIN
END;
END_PROC);
NOTI CE: CREATE OR REPLACE PROCEDURE cust omer ( ) RETURNS I NT4 LANGUAGE
NZPLSQL
AS' Tl pQU1FMV1J BUDEwWWk5NUhr QzVhR0xyRFRxTWR3VE5sQT09J EdFQ1B5LzVkSU1KMTI
1a0dUK3NTWj l kb3ZGL3ZHal hpVExPVG5Uaj RkK3gxSkxvZVhKej dZQmJ OVHN0aU1waFRl b
mhoaWt YdHJ UTVkKUUNr WDY5Nko5Rms2Nl BI YUxr a21xeWNZYXdWcl BCQT0=' ;
wr ap_pr oc
- - - - - - - - - - -
t
( 1 r ow)
When you call an obfuscated procedure, the system uses internal routines to read the
obfuscated body text and run the procedure. The behavior and output of the obfuscated
procedure is identical to a cleartext version of the procedure, for example:
TEST( USR) => CALL customer();
NOTI CE: The cust omer name i s al pha
cust omer
- - - - - - - - - -
( 1 r ow)
20470-02 Rev. 1 3-9
Creating Obfuscated Procedure Body Text
As an alternative to using the wrap_proc procedure method, you could also create the
obfuscated body of the procedure in a separate step as follows:
TEST( USR) => CALL wrap_nzplsql(BEGIN_PROC BEGIN RAISE NOTICE 'The
customer name is alpha'; END; END_PROC);
wr ap_nzpl sql
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Tl pQU1FMV1J BUDEwVE5j Zl h5TnpYbndCNkV5VFFMRTBi QT09J GE5N2p6ZEdJ SVZwTTRr Wm
RRM0I 3WmUxZERZeWd6Ykdj TWkxTzQr L1dCMmpqRGQvak9l UzFQQj Ar NGdl M08yZVdxUj RI
MTFaTnROUmwKdk5xSm0wb1RPZz09
( 1 r ow)
The wrap_nzplsql built-in procedure generates the obfuscated body text, which you can
input directly to a CREATE OR REPLACE PROCEDURE command, as follows:
TEST( USR) => CREATE OR REPLACE PROCEDURE customer() RETURNS INT4
LANGUAGE NZPLSQL AS
'TlpQU1FMV1JBUDEwVE5jZlh5TnpYbndCNkV5VFFMRTBiQT09JGE5N2p6ZEdJSVZwTTRrW
mRRM0I3WmUxZERZeWd6YkdjTWkxTzQrL1dCMmpqRGQvak9lUzFQQjArNGdlM08yZVdxUjR
IMTFaTnROUmwKdk5xSm0wb1RPZz09';
CREATE PROCEDURE
As shown in the example, you must enclose the obfuscated body text in single-quotes for
the CREATE OR REPLACE PROCEDURE command.
Creating Obfuscated Procedure Definitions for a Registration Script
If you plan to create a script that users will run to register your stored procedures in their
databases, you could use a wrapping procedure that takes as input the procedure definition
and body, and which returns a CREATE OR REPLACE PROCEDURE command that has
obfuscated body text. For example:
TEST( USR) => CREATE OR REPLACE PROCEDURE return_wrap(TEXT, TEXT)
RETURNS TEXT LANGUAGE NZPLSQL AS
BEGIN_PROC
DECLARE
proc alias for $1;
body alias for $2;
enc text;
sql text;
BEGIN
enc := wrap_nzplsql(body);
sql := proc || ' ' || '' || quote_literal(enc) || '';
return sql;
END;
END_PROC;
CREATE PROCEDURE
Similar to the wrap_proc example, specify the CREATE OR REPLACE main definition as a
quoted text string in the first input value, and specify the unquoted BEGIN PROC/END
PROC contents in the second input value. An example follows:
TEST( USR) => CALL return_wrap('CREATE OR REPLACE PROCEDURE customer()
RETURNS INT4 LANGUAGE NZPLSQL AS', BEGIN_PROC BEGIN RAISE NOTICE 'The
customer name is alpha'; END; END_PROC);
r et ur n_wr ap
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
CREATE OR REPLACE PROCEDURE cust omer ( ) RETURNS I NT4 LANGUAGE NZPLSQL
3-10 20470-02 Rev. 1
AS
' Tl pQU1FMV1J BUDEwaTVJ eHJ nV1BLd1o0ZDVt NEt NMGxKQT09J Ct i Sl VDS1NHbkVr dVZj a
01J R3Nr c2dTZl ExWDdkaUpDeHdZWUp2dml r UkZI eEpEQnR6dE1J SHMxOHRTR08xMG1I czJ
FSk92R2F0Ti 8KMGhKTGl UUEdI Zz09'
( 1 r ow)
The return value is a CREATE OR REPLACE PROCEDURE command that you could use in
your registration script to define your stored procedure without displaying the procedure
body text to the script user.
Calling or Invoking a Stored Procedure
To invoke or execute the sample stored procedure customer(), you can use any of the fol-
lowing SQL query forms:
TEST( USR) => CALL customer();
TEST( USR) => EXEC customer();
TEST( USR) => EXECUTE customer();
TEST( USR) => EXECUTE PROCEDURE customer();
TEST( USR) => SELECT customer();
Any of these commands cause the procedure to output the following:
NOTI CE: The cust omer name i s al pha
CUSTOMER
- - - - - - - - - -
( 1 r ow)
For more information about the CALL and EXEC[UTE[ PROCEDURE]] commands, refer to
Appendix A, SQL Reference.
Altering a Stored Procedure
After you define a stored procedure on the Netezza system, you can use the ALTER PROCE-
DURE command to change some aspects of the procedure. For more information about the
command, see ALTER PROCEDURE on page A-1.
You can modify a stored procedure to change the following aspects of the procedure:
RETURNS value
Execution user property (EXECUTE AS OWNER versus EXECUTE AS CALLER)
The body of the procedure
The owner of the procedure
You cannot change the procedure name or argument type list. You must drop the existing
procedure and create a new procedure with the new name and/or argument type list.
For example, the following sample commands could be used to change the customer pro-
cedure. To change the return value type, use a command similar to the following:
TEST( USR) => ALTER PROCEDURE customer() RETURNS INT8;
ALTER PROCEDURE
To change the owner of the procedure to user, use a command similar to the following:
TEST( USR) => ALTER PROCEDURE customer() OWNER TO user;
ALTER PROCEDURE
20470-02 Rev. 1 3-11
To change the user execution property to EXECUTE AS CALLER, use a command similar to
the following:
TEST( USR) => ALTER PROCEDURE customer() EXECUTE AS CALLER;
ALTER PROCEDURE
To change the procedure definition, use a command similar to the following:
TEST( USR) => ALTER PROCEDURE customer() AS
BEGIN_PROC
BEGIN
RAISE NOTICE 'The customer name is beta';
END;
END_PROC;
ALTER PROCEDURE
As a best practice, Netezza recommends that you add some descriptive comments on
stored procedures using the COMMENT ON command capability. For example:
COMMENT ON PROCEDURE customer() IS 'A procedure that displays a
customer name.';
COMMENT
A Netezza SQL query user can display these comments using the nzsql \dd <name> com-
mand switch, or the \dd switch which will show all comments for all procedures. As a best
practice, consider using a template of comments for all proceduresincluding information
about the author, version, and descriptionin the following format:
COMMENT ON PROCEDURE <pr ocedur e name> ( <ar gument t ype l i st >) I S
' Aut hor : <name>
Ver si on: <version>
Descr i pt i on: <description>' ;
For example:
COMMENT ON PROCEDURE customer() IS 'Author: bsmith
Version: 1.0 Description: A procedure that writes a customer name to
the database log file.';
To comment on a stored procedure, you must either be the Netezza admin user, the owner
of the procedure, or you must have Alter permissions for procedure objects. For more infor-
mation about COMMENT ON, refer to the Netezza Database Users Guide.
Make sure that you specify a full procedure name and argument list, including correct sizes
for numeric and string datatypes. Otherwise you will receive an error similar to the
following:
Er r or : Comment Pr ocedur e: exi st i ng pr ocedur e name( ar gument t ype l i st )
di f f er s i n si ze of st r i ng/ numer i c ar gument s
Dropping a Stored Procedure
You can remove a stored procedure from the Netezza system using the DROP PROCEDURE
command. For more information about the command, see DROP PROCEDURE on
page A-9.
3-12 20470-02 Rev. 1
For example, to drop the customer procedure, use a command similar to the following:
DROP PROCEDURE customer();
DROP PROCEDURE
Showing Information About a Stored Procedure
You can use the SHOW PROCEDURE command to display information about a stored pro-
cedure. A sample command follows for the example customer procedure:
MYDB( USR) => SHOW PROCEDURE customer;
RESULT | PROCEDURE | BUI LTI N | ARGUMENTS
- - - - - - - - - +- - - - - - - - - - - +- - - - - - - - - +- - - - - - - - - - -
I NTEGER | CUSTOMER | f | ( )
( 1 r ow)
The sample output shows the return value (RESULT), the procedure name, f (false) to indi-
cate that this is a user-defined procedure (not a built-in or system-supplied procedure), and
the argument list for the procedure (an empty list in this example).
The command displays information for any procedures with names that begin with the
specified characters. For example, if you have two procedures named customer and custo-
merid, this example command displays information for both procedures.
The command also offers a VERBOSE mode which displays more information about the
procedure, including the procedure body, comments (if supplied), owner, execution user,
and other information. If the procedure is obfuscated, the procedure body will not be in
clear text; it will be in an unreadable format. For details about the SHOW PROCEDURE
command, see SHOW PROCEDURE on page A-10.
If you use the NzAdmin administrative interface, you can view information about the stored
procedures defined on a Netezza system and manage them. You cannot add or alter a
stored procedure from the NzAdmin interface, but you can display its properties, change its
owner, drop the procedure, and manage user and group permissions for procedures.
To view the stored procedures, go to the Database tab of NzAdmin. Select a database and
double-click Procedures to list the stored procedures that are defined in that database.
Figure 3-1: The NzAdmin Stored Procedures Window
20470-02 Rev. 1 3-13
The Procedures list shows the signature, return type, owner, and creation date of each pro-
cedure. Double-click a procedure to obtain information about the procedure definition, or
to view or manage the privileges for the procedure. For more information about using the
NzAdmin interface, see the Netezza System Administrators Guide.
3-14 20470-02 Rev. 1
A-1
A P P E N D I X A
SQL Reference
This appendix describes the Netezza SQL commands that relate to the creation and man-
agement of stored procedures. Table A-1 lists the SQL commands.
ALTER PROCEDURE
Use the ALTER PROCEDURE command to change a stored procedure. You can change the
procedures return value, execution setting, owner, and procedure body, but you cannot
change the name or argument list using this command. (You can add or remove the
VARARGS value in an otherwise empty argument list.)
To change a stored procedures name and/or argument list, you must drop the procedure
and create a procedure with the new name and/or argument type list.
Synopsis
Syntax:
ALTER PROCEDURE <name> ( <args>) [ RETURNS <type>]
[ EXECUTE AS OWNER | EXECUTE AS CALLER ] [ AS <pr ocedur e_body>] ;
ALTER PROCEDURE <name> ( <args>) OWNER TO <user >;
Table A-1: Stored Procedure SQL Commands
Command Description More Information
ALTER PROCEDURE Changes a stored
procedure.
See ALTER PROCEDURE on
page A-1.
CALL or EXEC[UTE
[ PROCEDURE]]
Runs a stored procedure. See CALL and EXEC[UTE [PROCE-
DURE]] on page A-4
CREATE [OR REPLACE]
PROCEDURE
Adds or updates a stored
procedure.
See CREATE [OR REPLACE] PRO-
CEDURE on page A-6.
DROP PROCEDURE Drops or deletes a stored
procedure.
See DROP PROCEDURE on
page A-9.
SHOW PROCEDURE Displays information
about stored procedures.
See SHOW PROCEDURE on
page A-10.
A-2 20470-02 Rev. 1
Inputs
The ALTER PROCEDURE command takes the following inputs:
Outputs
The ALTER PROCEDURE command has the following output
Table A-2: ALTER PROCEDURE Input
Input Description
name The name of the stored procedure that you want to change. You
cannot change the name of the procedure.
args A list of input argument datatypes for the stored procedure. You
could also specify the VARARGS value to create a variable argu-
ment procedure where users could input up to 64 values of any
supported data type. VARARGS is a mutually exclusive value; you
cannot specify any other arguments in the list.
You cannot change the argument list or sizes. You can remove
VARARGS from the argument list, or add it to an otherwise empty
argument list.
RETURNS <type> Specifies the type of data returned by the procedure. The <type>
value can be a Netezza data type or the value REFTABLE (<table-
name>) to indicate that it returns a result set that looks like the
specified table. The table must exist, and it continue to exist after
the procedure. The table could be empty, but it must exist in the
database. For more information about returning a result set, see
Returning a Result Set on page 2-23.
EXECUTE AS
OWNER
If specified, the stored procedure uses the procedure owner ID for
all access control and permission checks. This is the default.
EXECUTE AS
CALLER
If specified, the stored procedure uses the ID of the user who
called the procedure for all access control and permission checks.
procedure_body Specifies the text or body of the procedure. The body must be
enclosed with single quotes or enclosed by a BEGIN_PROC/END_
PROC pair.
When you alter the procedure, you can obfuscate the body to mask
the content from users who have permission to show the procedure.
For more information, see Obfuscating the Procedure Body on
page 3-7.
Table A-3: ALTER PROCEDURE Output
Output Description
ALTER PROCEDURE The message that the system returns if the command is
successful.
20470-02 Rev. 1 A-3
ALTER PROCEDURE
Description
You cannot alter a stored procedure that is currently in use in an active query. After the
active querys transaction completes, the Netezza system will process the ALTER PROCE-
DURE command.
Privileges Required
To alter a procedure, you must meet one of the following criteria:
You must have the Alter privilege on the PROCEDURE object.
You must have the Alter privilege on the specific procedure.
You must own the procedure.
You must be the database admin user or own the current database.
Common Tasks
You can use the ALTER PROCEDURE command to change the execution user ID of the pro-
cedure, its return value, or the procedure body itself.
You can also use the ALTER PROCEDURE command to change the owner of a procedure as
follows:
ALTER PROCEDURE <name> (<arguments>) OWNER TO <name>;
Related Commands
See CALL and EXEC[UTE [PROCEDURE]] on page A-4 to invoke procedures.
See CREATE [OR REPLACE] PROCEDURE on page A-6 to create procedures.
See DROP PROCEDURE on page A-9 to drop procedures.
See SHOW PROCEDURE on page A-10 to display information about the procedure.
ERROR: replacing procedure:
permission denied.
The message indicates that the user does not have Alter
permission on the procedure. For more information, see
Managing User Account Permissions on page 3-1.
Error: FunctionAlter: existing
UDX NAME(ARGS) differs in
size of string/numeric
arguments
This error indicates that a stored procedure exists with
the name but has different sizes specified for string or
numeric arguments.
To alter the stored procedure, make sure that you specify
the exact argument type list with correct sizes.
ERROR: FunctionAlter: func-
tion NAME does not exist with
that signature
This error indicates that the specified procedure name
does not exist in the database.
ERROR: Can't specify argu-
ments to a varargs procedure
You cannot specify both the VARARGS value and any
other argument value in the arguments list. The
VARARGS value is mutually exclusive.
Table A-3: ALTER PROCEDURE Output
Output Description
A-4 20470-02 Rev. 1
Usage
The following provides sample usage.
To change the execution ID from over to caller, enter:
syst em( admi n) => ALTER PROCEDURE myproc(int4) EXECUTE AS CALLER;
CALL and EXEC[UTE [PROCEDURE]]
Use the CALL command, EXEC command, EXECUTE command, or EXECUTE PROCEDURE
command to invoke a stored procedure on a Netezza host. You can also use the SELECT
command. The commands are identical in behavior, inputs, and outputs. The command
variations provide for some compatibility with other procedural language invocation
methods.
Synopsis
Syntax:
CALL procedure_name( arguments)
EXEC procedure_name( arguments)
EXECUTE procedure_name( arguments)
EXECUTE PROCEDURE procedure_name( arguments)
SELECT procedure_name( arguments)
Inputs
The CALL and EXEC[UTE [PROCEDURE] commands take the following inputs:
Outputs
The CALL and EXEC[UTE [PROCEDURE] commands have the following outputs:
Table A-4: CALL and EXEC[UTE [PROCEDURE]] Input
Input Description
procedure_name The name of the stored procedure that you want to invoke.
arguments Specifies a list of constant or literal arguments to the procedure.
The arguments may be results of functions, as long as the func-
tions take only constant/literal arguments as well.
Table A-5: CALL and EXEC[UTE [PROCEDURE]] Output
Output Description
ERROR: EXECUTE
PROC: Permission
denied.
This error indicates that the current user account does not have
Execute permission for the stored procedure. For more information
about permissions, see Managing User Account Permissions on
page 3-1.
20470-02 Rev. 1 A-5
CALL and EXEC[UTE [PROCEDURE]]
Description
The following sections describe the privileges and related commands.
Privileges Required
To invoke a stored procedure, you must meet one of the following criteria:
You must have the Execute privilege on the PROCEDURE object.
You must have the Execute privilege on the specific procedure.
You must own the procedure.
Related Commands
See ALTER PROCEDURE on page A-1 to change procedures.
Usage
The following examples provide some sample usage:
MYDB( USER) => CALL updateacct();
MYDB( USER) => EXEC myproc();
MYDB( USER) => EXECUTE inventorysearch(umbrellas);
MYDB( USER) => EXECUTE PROCEDURE updateacct();
You can also use the SELECT command to run a procedure; however, you cannot specify a
FROM clause. For example:
MYDB( USER) => SELECT updateacct();
MYDB( USER) => SELECT inventorysearch(umbrellas);
ERROR: Function
'NAME(ARGS)' does
not exist
Unable to identify a
function that satis-
fies the given
argument types
You may need to add
explicit typecasts
This message indicates that the user entered incorrect arguments
for the stored procedure. A procedure of that name exists, but it is
expecting different input arguments.
Table A-5: CALL and EXEC[UTE [PROCEDURE]] Output (continued)
Output Description
A-6 20470-02 Rev. 1
Use the CREATE PROCEDURE command to create a new stored procedure. Use CREATE
OR REPLACE PROCEDURE to create a new stored procedure or to update an existing pro-
cedure with a new return type, execution permissions, or procedure body.
Synopsis
Syntax:
CREATE [ OR REPLACE] PROCEDURE <name> ( <arguments>)
RETURNS <type> [ [ EXECUTE AS OWNER | EXECUTE AS CALLER ] ] LANGUAGE
NZPLSQL AS <pr ocedur e_body>;
Inputs
The CREATE OR REPLACE PROCEDURE command takes the following inputs:
Table A-6: CREATE OR REPLACE PROCEDURE Input
Input Description
name The name of the stored procedure that you want to create or
replace. This is the SQL identifier that will be used to invoke the
procedure in a SQL expression.
If the stored procedure already exists, you cannot change the name
using the CREATE OR REPLACE command.
arguments Specifies a list of fully-specified argument data types. You could
also specify the VARARGS value to create a variable argument pro-
cedure where users could input up to 64 values of any supported
data type. VARARGS is a mutually exclusive value; you cannot
specify any other arguments in the list.
If the stored procedure already exists, you cannot change the argu-
ment type list using the CREATE OR REPLACE command. You can
change some aspects of the argument types; for example, you can
change the size of a string or the precision and scale of a numeric
value. You can also remove VARARGS from the argument list, or
add it to an otherwise empty argument list.
RETURNS <type> Specifies the type of data returned by the procedure. The <type>
value can be a Netezza data type or the value REFTABLE (<table-
name>) to indicate that it returns a result set that looks like the
specified table. The table must exist although it can be
empty and it continues to exist after the procedure. For more
information about returning a result set, see Returning a Result
Set on page 2-23.
EXECUTE AS
OWNER
If specified, the stored procedure runs using the procedure owner
ID for all access control and permission checks. This is the default.
EXECUTE AS
CALLER
If specified, the stored procedure runs using the ID of the user who
called the procedure for all access control and permission checks.
20470-02 Rev. 1 A-7
Outputs
The CREATE [OR REPLACE] PROCEDURE command has the following output:
LANGUAGE Specifies the programming language used for the procedure. The
default and only supported value is NZPLSQL.
procedure_body Specifies the text of the procedure and must be enclosed with sin-
gle quotes or a BEGIN_PROC/END_PROC pair.
You can obfuscate the body to mask the content from users who
have permission to show the procedure. For more information, see
Obfuscating the Procedure Body on page 3-7.
Table A-6: CREATE OR REPLACE PROCEDURE Input (continued)
Input Description
Table A-7: CREATE [OR REPLACE] PROCEDURE Output
Output Description
CREATE PROCEDURE The message that the system returns if the command is
successful.
ERROR: creating procedure:
permission denied.
The message indicates that the user does not have Cre-
ate Procedure permission. For more information, see
Managing User Account Permissions on page 3-1.
ERROR: User 'username' is not
allowed to create/drop
procedures.
The system returns this message if your user account
does not have permission to create a stored procedure.
ERROR: Synonym 'name'
already exists
The system returns this message if a synonym already
exists with the name that you specified for the stored
procedure.
ERROR: ProcedureCreate: pro-
cedure NAME already exists
with the same signature
This error is returned when you issue a CREATE PROCE-
DURE command and a stored procedure with the same
name and argument type list already exists in the data-
base. Use CREATE OR REPLACE PROCEDURE instead.
NOTICE: FunctionCreate:
existing UDX NAME(ARGS) dif-
fers in size of string/numeric
arguments
This message indicates that a stored procedure already
exists with the name but has different sizes specified for
string or numeric arguments. If you did not intend to
change the stored procedure signature, you should
check the signature and ensure that it is correct.
ERROR: Can't specify argu-
ments to a varargs procedure
You cannot specify both the VARARGS value and any
other argument value in the arguments list. The
VARARGS value is mutually exclusive.
A-8 20470-02 Rev. 1
Description
When you create a stored procedure, note that the stored procedures signature (that is, its
name and argument type list) must be unique within its database. No other stored proce-
dure can have the same name and argument type list in the same database.
You cannot change the stored procedure name or the argument type list using the CREATE
OR REPLACE command. You can change some aspects of the argument types; for example,
you can change the size of a string or the precision and scale of a numeric value, and you
can add or remove the VARARGS value in an otherwise empty argument list. To change a
stored procedures name and/or argument type list, you must drop the stored procedure and
then create a stored procedure with the new name and/or argument type list.
You cannot replace a stored procedure that is currently in use in an active query. After the
active querys transaction completes, the Netezza system will process the CREATE OR
REPLACE PROCEDURE command.
Privileges Required
You must have Create Procedure permission to use the CREATE PROCEDURE command.
Also, if you use CREATE OR REPLACE PROCEDURE to change a stored procedure, you
must have Create Procedure and Alter permission to change it.
Common Tasks
Use the CREATE PROCEDURE command to create and become the owner of a new stored
procedure. You can use the ALTER PROCEDURE command to change the owner of a
procedure.
Related Commands
See ALTER PROCEDURE on page A-1 to change procedures.
Usage
To create a new procedure called customername:
syst em( admi n) => CREATE OR REPLACE PROCEDURE customer() RETURNS INT8
LANGUAGE NZPLSQL AS BEGIN_PROC BEGIN RAISE NOTICE 'The customer
name is alpha'; END; END_PROC;
20470-02 Rev. 1 A-9
DROP PROCEDURE
DROP PROCEDURE
Use the DROP PROCEDURE command to remove an existing stored procedure from a
database.
Synopsis
Syntax:
DROP PROCEDURE <name> ( <arguments>)
Inputs
The DROP PROCEDURE command takes the following inputs:
Outputs
The DROP PROCEDURE command has the following output:
Table A-8: DROP PROCEDURE Input
Input Description
name The name of the stored procedure that you want to drop.
arguments A list of input arguments to uniquely identify the stored procedure.
Table A-9: DROP PROCEDURE Output
Output Description
DROP PROCEDURE The message that the system returns if the command is
successful.
ERROR: DROP PROCEDURE:
permission denied
The user does not have Drop permission. For more infor-
mation about permissions, see Managing User Account
Permissions on page 3-1.
ERROR: RemoveFunction:
function 'NAME(ARGS)' does
not exist
The message which indicates that the specified proce-
dure signature does not exist in the database.
ERROR: Name: No such stored
procedure
The message that the system returns if the specified
stored procedure does not exist in the current database.
ERROR: RemoveFunction:
existing UDX NAME(ARGS) dif-
fers in size of string/numeric
arguments
This error indicates that a stored procedure exists with
the name but has different sizes specified for string or
numeric arguments.
To drop the stored procedure, make sure that you specify
the exact argument type list with correct sizes.
A-10 20470-02 Rev. 1
Description
You cannot drop a stored procedure that is currently in use in an active query. After the
active querys transaction completes, the Netezza system will process the DROP PROCE-
DURE command. The stored procedure must be defined in the current database.
The DROP PROCEDURE command has the following characteristics:
Privileges Required
To drop a stored procedure, you must meet one of the following criteria:
You must have the Drop privilege on the PROCEDURE object.
You must have the Drop privilege on the specific stored procedure.
You must own the stored procedure.
Common Tasks
Use the DROP PROCEDURE command to drop an existing stored procedure from a
database.
Related Commands
See ALTER PROCEDURE on page A-1 to alter stored procedures.
Usage
To drop a sample stored procedure named mycalc, enter:
syst em( admi n) => DROP PROCEDURE mycalc();
SHOW PROCEDURE
Use the SHOW PROCEDURE command to display information about one or more stored
procedures. The command checks your user account privileges to ensure that you are per-
mitted to see information about the procedures defined in the database.
Synopsis
Syntax:
SHOWPROCEDURE [ ALL | <name>] [ VERBOSE]
20470-02 Rev. 1 A-11
SHOW PROCEDURE
Inputs
The SHOW PROCEDURE command takes the following inputs:
Outputs
The SHOW PROCEDURE command has the following output:
Description
The SHOW PROCEDURE command has the following characteristics:
Privileges Required
Any user can run the SHOW PROCEDURE command. To see information about procedures
in the output, you must be the admin user, own one or more procedures, own the current
database, or have object privileges (such as Execute, List, Alter, or Drop) on one or more
procedures or the Procedure object class.
Common Tasks
Use the SHOW PROCEDURE command to display one or all stored procedures in a
database.
Related Commands
See ALTER PROCEDURE on page A-1 to alter stored procedures.
See DROP PROCEDURE on page A-9 to drop a stored procedure.
Table A-10: SHOW PROCEDURE Input
Input Description
ALL Show information about all the stored procedures defined in the
database. This is the default.
name Show information about one or more stored procedures defined in
the database. You can specify a partial name. The command dis-
plays information for all the procedures with names that begin with
the specified characters. You cannot specify a full signature.
VERBOSE Display detailed information about the stored procedure.
Table A-11: SHOW PROCEDURE Output
Output Description
error found "(" (at char num)
syntax error, unexpected '(',
expecting $end
The message that the system returns if you specify a full
signature, for example:
show pr ocedur e r et ur nt wo( ) ;
A-12 20470-02 Rev. 1
Usage
To show the sample stored procedure named returntwo, use the following command:
MYDB( ADMI N) => SHOW PROCEDURE returntwo;
- - - - - - - - - - - - - - - - - - - - - - - - - - +- - - - - - - - - - - +- - - - - - - - - +- - - - - - - - - - - - -
REFTABLE( MYDB. USER. TBL) | RETURNTWO | f | ( TI MESTAMP)
( 1 r ow)
To show verbose information for the sample stored procedure named returntwo, use the
following command. (Note that the sample output below is formatted to fit the page
area.)
DEV( ADMI N) => SHOW PROCEDURE returntwo VERBOSE;
RESULT | PROCEDURE | BUI LTI N | ARGUMENTS | OWNER | EXECUTEDASOWNER |
VARARGS | DESCRI PTI ON | PROCEDURESOURCE
- - - - - - - - - - - - - - - - - - - - - - - - - +- - - - - - - - - - - +- - - - - - - - - +- - - - - - - - - - - - - +- - - - - - - +- - - - - - - - - - - - - - - - - +
- - - - - - - - +- - - - - - - - - - - - - - +- - - - - - - - - - - - - - - - -
REFTABLE( MYDB. USER. TBL) | RETURNTWO | f | ( TI MESTAMP) | USER | t |
f | Thi s i s a sampl e st or ed pr ocedur e |
DECLARE
BEGI N
EXECUTE I MMEDI ATE ' I NSERT I NTO ' | | REFTABLENAME | | ' val ues ( 1, 1) ' ;
EXECUTE I MMEDI ATE ' I NSERT I NTO ' | | REFTABLENAME | | ' val ues ( 2, 2) ' ;
RETURN REFTABLE;
END;
( 1 r ow)
If the stored procedure is obfuscated, the VERBOSE mode shows the obfuscated body
text, as follows:
DEV( ADMI N) => SHOW PROCEDURE customer VERBOSE;
RESULT | PROCEDURE | BUI LTI N | ARGUMENTS | OWNER | EXECUTEDASOWNER | VARARGS |
DESCRI PTI ON | PROCEDURESOURCE
- - - - - - - - - - - - - - - - - - - - - - - - - +- - - - - - - - - - - +- - - - - - - - - +- - - - - - - - - - - - - +- - - - - - - +- - - - - - - - - - - - - - - - - +
- - - - - - - - +- - - - - - - - - - - - - - +- - - - - - - - - - - - - - - - -
BI GI NT | CUSTOMER | f | ( ) | USR | t | f |
| Tl pQU1FMV1J BUDEwVE5j Zl h5TnpYbndCNkV5VFFMRTBi QT09J GE5N2p6ZEdJ SVZwTTRr WmRRM0I 3
WmUxZERZeWd6Ykdj TWkxTzQr L1dCMmpqRGQvak9l UzFQQj Ar NGdl M08yZVdxUj RI MTFaTnROUmwKdk5xSm0wb1RPZz
09
( 1 r ow)
To list all the stored procedures in a database, enter:
DEV( ADMI N) => SHOW PROCEDURE ALL;
- - - - - - - - - - - - - - - - - - - - - - - - - - - - +- - - - - - - - - - - - - - - - - - +- - - - - - - - - +- - - - - - - - - - - - - - - - - - - - - - - -
BOOLEAN | BOOLPROC | f | ( BOOLEAN)
CHARACTER | CHARPROC | f | ( CHARACTER( ANY) )
CHARACTER | CHARPROCANY | f | ( CHARACTER( ANY) )
CHARACTER | CHARPROCANY2 | f | ( CHARACTER( 10) )
REAL | FLOAT4PROC | f | ( REAL)
DOUBLE PRECI SI ON | FLOAT8PROC | f | ( DOUBLE PRECI SI ON)
BYTEI NT | I NT1PROC | f | ( BYTEI NT)
B-1
A P P E N D I X B
Stored Procedure Examples
Whats in this appendix
Example of Simulating an Anonymous Block
This appendix contains examples of stored procedure definitions.
Variable Argument Stored Procedure
The following is an example of a stored procedure that uses variable arguments and the
$var value to obtain the data type of the input parameters:
CREATE OR REPLACE PROCEDURE sp_var ar gs01( var ar gs)
RETURNS I NT4
LANGUAGE NZPLSQL
AS
BEGI N_PROC
DECLARE
num_ar gs i nt 4;
t yp oi d;
i dx i nt 4;
BEGI N
num_ar gs : = PROC_ARGUMENT_TYPES. count ;
RAI SE NOTI CE ' Number of ar gument s i s %' , num_ar gs;
f or i I N 0 . . PROC_ARGUMENT_TYPES. count - 1 LOOP
t yp : = PROC_ARGUMENT_TYPES( i ) ;
i dx : = i +1;
RAI SE NOTI CE ' ar gument $%i s t ype %val ue ' ' %' ' ' , i dx, t yp,
$i dx;
END LOOP;
END;
END_PROC;
A sample call to the sp_varargs01 procedure follows:
select sp_varargs01(true, 'test'::char(10), 62443234::int8, 123::int2,
123456::int4, 34343.4343::float4, 1212.2323::float8,
'test2'::varchar(10), '2009-05-12'::date, '13:14:05'::time, '2009-05-
12 08:10:10'::timestamp, '2 days 1 hour'::interval,
'11:40:36+05'::timetz, 3243.4324234::numeric,
3243.4324234::numeric(7,2), 5::int1, 'foo'::nchar(20),
'foo'::nvarchar(20), null::int4);
NOTI CE: Number of ar gument s i s 19
NOTI CE: ar gument $1 i s t ype 16 val ue ' t '
NOTI CE: ar gument $2 i s t ype 1042 val ue ' t est '
B-2 20470-02 Rev. 1
NOTI CE: ar gument $3 i s t ype 20 val ue ' 62443234'
NOTI CE: ar gument $6 i s t ype 700 val ue ' 34343. 4'
NOTI CE: ar gument $8 i s t ype 1043 val ue ' t est 2'
NOTI CE: ar gument $9 i s t ype 1082 val ue ' 2009- 05- 12'
NOTI CE: ar gument $10 i s t ype 1083 val ue ' 13: 14: 05'
NOTI CE: ar gument $11 i s t ype 1184 val ue ' 2009- 05- 12 08: 10: 10'
NOTI CE: ar gument $12 i s t ype 1186 val ue ' 2 days 01: 00: 00'
NOTI CE: ar gument $13 i s t ype 1266 val ue ' 11: 40: 36+05'
NOTI CE: ar gument $17 i s t ype 2522 val ue ' f oo '
NOTI CE: ar gument $18 i s t ype 2530 val ue ' f oo'
NOTI CE: ar gument $19 i s t ype 23 val ue ' <NULL>'
sp_var ar gs01
- - - - - - - - - - - - - -
( 1 r ow)
The following is an NZPLSQL procedure that can execute anonymous blocks:
CREATE OR REPLACE PROCEDURE exec_nzpl sql _bl ock( t ext ) RETURNS BOOLEAN
LANGUAGE NZPLSQL AS
BEGI N_PROC
DECLARE l Ret BOOLEAN;
DECLARE si d I NTEGER;
DECLARE nmvar char ;
DECLARE cr var char ;
BEGI N
si d : = cur r ent _si d;
nm: = ' any_bl ock' | | si d | | ' ( ) ' ;
cr = ' CREATE OR REPLACE PROCEDURE ' | | nm| |
' RETURNS BOOL LANGUAGE NZPLSQL AS BEGI N_PROC '
| | $1 | | ' END_PROC' ;
EXECUTE I MMEDI ATE cr ;
EXECUTE I MMEDI ATE ' SELECT ' | | nm;
EXECUTE I MMEDI ATE ' DROP PROCEDURE ' | | nm;
RETURN TRUE;
END;
END_PROC;
An example call and output follows:
DEV( ADMI N) => call exec_nzplsql_block(BEGIN_PROC DECLARE var char;
BEGIN var:= 'test'; raise NOTICE 'This is a %', var; END; END_PROC);
NOTI CE: Thi s i s a t est
EXEC_NZPLSQL_BLOCK
- - - - - - - - - - - - - - - - - - - -
t
( 1 r ow)
20470-02 Rev. 1 B-3
B-4 20470-02 Rev. 1
Index
Index-1
Index
Symbols
$var variable 2-4
%, used in message formats 2-21
A
account permissions, managing 3-1
admin user, permissions 3-1
aliases, for data types 2-6
ALTER PROCEDURE command A-1
using 3-10
ANY keyword 3-6
ANY keyword, for procedure input arguments 3-5
arithmetic evaluations, and stored procedures 2-10
array variables
assigning a value 2-9
in NZPLSQL 2-9
reference support 2-9
assignment statement 2-14
B
backups, and stored procedures 1-6
BEGIN_PROC keyword 1-5
best practices, stored procedures 1-4
block comments 2-2
block quoting support 1-5
block structured language 2-1
block, in NZPLSQL 2-1
C
CALL command
discarding results 2-14
example 3-10
usage A-4
call recursion limit 2-15
casting
impact on stored procedures 2-11
input values to match signature sizes 3-6
COMMENT ON PROCEDURE command, using 3-11
comments
best practices 3-11
in NZPLSQL 2-2
conditional control 2-16
CONSTANT option, variables 2-3
constants, in NZPLSQL 2-2
control statements
conditional 2-16
iterative 2-17
control structures 2-16
COUNT method, array variables 2-9
CREATE OR REPLACE PROCEDURE command A-6
generic arguments example 3-7
using 3-3
cross-database access, to stored procedures 1-4
D
data types 2-6
DEBUG messages 2-21
declarations section, in NZPLSQL 2-2
DEFAULT clause, variables 2-3
disk space problems, avoiding for large datasets 2-25
double dash comments 2-2
downgrade cautions 1-7
DROP PROCEDURE command A-9
using 3-11
dropping when database is dropped 1-6
dynamic queries 2-15
E
ELSE IF statement 2-17
ELSIF statement 2-17
END_PROC keyword 1-5
error handling, in NZPLSQL 2-22
errors, raising 2-21
EXCEPTION messages 2-21
EXCEPTION statement 2-22
EXEC command, using 3-10
execute as caller permissions 1-4
execute as owner permissions 1-4
EXECUTE command A-4
using 3-10
EXECUTE IMMEDIATE statement 2-15
EXECUTE PROCEDURE command, using 3-10
EXIT statement 2-18
expressions
in NZPLSQL 2-9
string processing best practices 2-15
EXTEND method, array variables 2-9
F
FOR IN loop statement 2-20
FOR loop, iteration step count 2-19
FOR statement 2-19
FOR-IN EXECUTE statement 2-21
fully-qualified object names, for stored procedures 1-4
G
generic arguments, benefits of 3-5
generic procedures
ANY keyword 3-6
input arguments 3-6
registering 3-7
generic return value 3-7
GRANT ALL command, create permission 3-2
GRANT command
alter permission 3-2
create permission 3-2
drop permission 3-3
execute permission 3-2
Index-2
Index
H
hiding the procedure body 3-7
I
IF statements 2-16
IF-THEN statements 2-16
IF-THEN-ELSE IF statement 2-17
IF-THEN-ELSE statements 2-16
implicit casting
for procedure input values 3-6
in assignments 2-14
in stored procedures, best practices 2-10
infinite loop, handling 2-26
iterative control 2-17
L
labels, used to identify variables 2-5
large datasets, managing 2-25
LAST_OID variable 2-15
loop processing 2-26
LOOP statement 2-17
loops
infinite, handling 2-26
iterate over integer count 2-19
repeating while true 2-18
terminating 2-18
unconditional 2-17
M
massively parallel processing (MPP), designing procedures
for 2-26
message levels, types of 2-21
messages, reporting 2-21
N
Netezza SQL commands
for stored procedures 1-2
reference A-1
NOT NULL option, variables 2-3
NOTICE messages 2-21
NzAdmin administrative interface, for stored procedures
3-12
NZPLSQL language
about 1-2
array variables 2-9
comments 2-2
constants 2-2
control structures 2-16
description of 2-1
dynamic queries 2-15
exception support 2-22
expressions 2-9
message and error reporting 2-21
procedural logic 1-2
record assignments 2-19
record variable 2-19
records 2-19
statements 2-14
variable datatypes 2-2
variables 2-2
O
obfuscating procedures
using in registration scripts 3-9
using wrap_nzplsql 3-7
outputs
CREATE OR REPLACE PROCEDURE command A-7
DROP PROCEDURE command A-9
SHOW PROCEDURE command A-11
overflows, avoiding in stored procedures 2-11
overloading procedures 3-4
owner, stored procedure 3-1
P
parameters 2-4
patches, and stored procedures 1-7
PATH SQL session variable 1-4
permissions
granting
all 3-2
create 3-2
drop permission 3-3
managing 3-1
revoking
create permission 3-2
drop permission 3-3
PL/pgSQL language 1-2
privileges, commands
CALL or EXECUTE PROCEDURE command A-5
CREATE PROCEDURE command A-8
privileges, managing for accounts 3-1
PROC_ARGUMENT_TYPES array 2-4
procedural programming language 1-1
procedures
calling 2-14
obfuscating 3-7
returning from 2-16
Q
quote_ident function 2-15
quote_literal function 2-15
R
RAISE statement 2-21
RECORD variable 2-19
Index
Index-3
records
about 2-19
assignments 2-19
recursion limit, calls 2-15
registration script, with obfuscated procedures 3-9
restores, and stored procedures 1-6
RETURN command 2-16
return value, generic 3-7
REVOKE command
drop permission 3-3
ROW_COUNT variable 2-15
%ROWTYPE attribute 2-3
S
scoping, variables 2-5
SHOW PROCEDURE command A-10
using 3-12
signature
about 3-4
used in permissions 3-1
SQL commands, for stored procedures A-1
SQLERRM variable 2-22
statements
assignment 2-14
in NZPLSQL 2-14
section, in NZPLSQL 2-2
stored procedures 1-4, 1-6
about 1-1
account permission overview 3-1
altering 3-10, A-1
benefits of 1-2
best practices 1-4
block quoting support 1-5
call recursion limit 2-15
calling, executing 3-10
commenting on 3-11
creating 1-3, 3-3
creating or replacing A-6
designing 3-3
displaying information for 3-12
dropping 3-11, A-9
example use of 1-1
executing 1-3
fully qualified name of 1-4
generic, registering 3-7
impact of implicit casting 2-11
input 1-3
invoking
CALL A-4
using EXECUTE A-4
limitations of size-specific input arguments 3-5
loop processing 2-26
managing 3-1
math best practices 2-10
obfuscating the body 3-7
owner of 3-1
PATH session variable 1-4
process to create 3-3
result sets 1-3
return types 1-3
security and access controls 1-2
security considerations 1-4
See also procedures.
showing A-10
signature 3-4
user of 3-1
strings, processing in expressions 2-15
T
TRIM method, array variables 2-9
%TYPE attribute 2-3
U
unconditional loop 2-17
upgrades, and stored procedures 1-7
V
VARARGS keyword 2-4, 3-7
variable arguments, benefits of 3-7
variable scoping 2-5
variables
datatypes 2-2
in NZPLSQL 2-2
W
WHILE statement 2-18
wrap_nzplsql built-in procedure 3-8
Index-4
Index

Netezza Stored Procedures Guide 1

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Netezza Stored Procedures Guide 1

Încărcat de

Drepturi de autor:

Formate disponibile

Netezza Corporation

S-ar putea să vă placă și