pgsql: Properly handle empty arrays returned from plperl functions.
Properly handle empty arrays returned from plperl functions.
Bug reported by David Wheeler, fix by Alex Hunsaker.
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: src/pl/plperl/plperl.c
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# autom4te.cache/
# configure.in~
# doc/src/sgml/ref/grant.sgml~
# src/backend/port/win32_latch.c~
# src/bin/psql/command.c~
# src/include/pg_config.h.win32~
# src/pl/plpython/plpython.c~
# src/tools/msvc/pgbison.bat~
# src/tools/msvc/pgbison.pl.bak
# src/tools/msvc/pgflex.bat~
# src/tools/msvc/pgflex.pl.bak
# src/tools/pgindent/README~
# src/tools/pgindent/pgindent.pl
# src/tools/pgindent/pgindent.pl~
# xxxxx
# yyyyyy
Branch
------
REL9_1_STABLE
Details
-------
http://git.postgresql.org/pg/commitdiff/22a55b3af687806e6b3a08a131d00541774eaade
Modified Files
--------------
src/pl/plperl/plperl.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
Wow, sorry for the noise. I guess I'll be more careful about reusing a
commit-message file.
cheers
andrew
Show quoted text
On 08/17/2011 12:04 PM, Andrew Dunstan wrote:
Properly handle empty arrays returned from plperl functions.
Bug reported by David Wheeler, fix by Alex Hunsaker.
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# (use "git reset HEAD<file>..." to unstage)
#
# modified: src/pl/plperl/plperl.c
#
# Untracked files:
# (use "git add<file>..." to include in what will be committed)
#
# autom4te.cache/
# configure.in~
# doc/src/sgml/ref/grant.sgml~
# src/backend/port/win32_latch.c~
# src/bin/psql/command.c~
# src/include/pg_config.h.win32~
# src/pl/plpython/plpython.c~
# src/tools/msvc/pgbison.bat~
# src/tools/msvc/pgbison.pl.bak
# src/tools/msvc/pgflex.bat~
# src/tools/msvc/pgflex.pl.bak
# src/tools/pgindent/README~
# src/tools/pgindent/pgindent.pl
# src/tools/pgindent/pgindent.pl~
# xxxxx
# yyyyyyBranch
------
REL9_1_STABLEDetails
-------
http://git.postgresql.org/pg/commitdiff/22a55b3af687806e6b3a08a131d00541774eaadeModified Files
--------------
src/pl/plperl/plperl.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
Excerpts from Andrew Dunstan's message of mié ago 17 12:41:47 -0400 2011:
Wow, sorry for the noise. I guess I'll be more careful about reusing a
commit-message file.
Happened to me once too (back when we used CVS). It seems the filter to
remove unwanted lines is not applied when the file is specified in the
command line which seems a bit silly to me.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On 08/17/2011 12:53 PM, Alvaro Herrera wrote:
Excerpts from Andrew Dunstan's message of mié ago 17 12:41:47 -0400 2011:
Wow, sorry for the noise. I guess I'll be more careful about reusing a
commit-message file.Happened to me once too (back when we used CVS). It seems the filter to
remove unwanted lines is not applied when the file is specified in the
command line which seems a bit silly to me.
Right, certainly a violation of POLA.
cheers
andrew
On Wed, Aug 17, 2011 at 01:29:01PM -0400, Andrew Dunstan wrote:
On 08/17/2011 12:53 PM, Alvaro Herrera wrote:
Excerpts from Andrew Dunstan's message of mi� ago 17 12:41:47 -0400 2011:
Wow, sorry for the noise. I guess I'll be more careful about reusing a
commit-message file.Happened to me once too (back when we used CVS). It seems the filter to
remove unwanted lines is not applied when the file is specified in the
command line which seems a bit silly to me.Right, certainly a violation of POLA.
It is indeed. What script or scripts handle this?
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
On 08/17/2011 04:59 PM, David Fetter wrote:
On Wed, Aug 17, 2011 at 01:29:01PM -0400, Andrew Dunstan wrote:
On 08/17/2011 12:53 PM, Alvaro Herrera wrote:
Excerpts from Andrew Dunstan's message of mi� ago 17 12:41:47 -0400 2011:
Wow, sorry for the noise. I guess I'll be more careful about reusing a
commit-message file.Happened to me once too (back when we used CVS). It seems the filter to
remove unwanted lines is not applied when the file is specified in the
command line which seems a bit silly to me.Right, certainly a violation of POLA.
It is indeed. What script or scripts handle this?
It's not a script. "git commit -F filename" is the culprit. It seems if
you intend to reuse the message file that git carefully saves for you,
you need to trim the comment lines. What I did was in the master branch,
"git commit -a" and then in the 9.1 branch "git commit -a -F
/path/to/master/.git/COMMIT_EDITMSG" to reuse the commit message, not
realizing it would not trim the comment lines if I use -F, unlike when
it puts me into the editor.
cheers
andrew
On Wed, Aug 17, 2011 at 5:17 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
It's not a script. "git commit -F filename" is the culprit. It seems if you
intend to reuse the message file that git carefully saves for you, you need
to trim the comment lines. What I did was in the master branch, "git commit
-a" and then in the 9.1 branch "git commit -a -F
/path/to/master/.git/COMMIT_EDITMSG" to reuse the commit message, not
realizing it would not trim the comment lines if I use -F, unlike when it
puts me into the editor.
Another way to do it is, if you're back-patching to another branch
after commiting on master, you can do:
git commit -c master
Which throws you into the editor, but loads the commit message,
author, and timestamp from the latest commit on that branch. Or you
can use any other way of referring to a commit - e.g. master~1, SHA,
etc.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company