Обсуждение: 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 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 > # 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(-) > >
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