Re: [PATCHES] Better formatting of functions in pg_dump
Tom Lane wrote:
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
Why the random switching between newline-before and newline-after
styles? Please be consistent.
I thought they were all "after". On second glance, they still seem
all after?
Oh, my mistake, I had failed to see that the patch was getting rid of
newline-before style in this function. I think you might have gone
a bit overboard on adding whitespace, but the previous objection is
nonsense, sorry.
Yeah, I like idea of moving the "metadata" stuff before the function
body, but the whitespace is a bit too much. You can fit
" LANGUAGE plpgsql IMMUTABLE STRICT SECURITY DEFINER COST 10" in
on one line without wrapping on a 80 col terminal. And we don't try to
guarantee any specific width anyway, you can get very long lines if the
function has a lot of arguments, for example.
I applied this simpler patch that just moves the "metadata" stuff before
the function body, leaving the whitespace as is (in newline-before style).
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
*** src/bin/pg_dump/pg_dump.c
--- src/bin/pg_dump/pg_dump.c
***
*** 6775,6788 dumpFunc(Archive *fout, FuncInfo *finfo)
rettypename = getFormattedTypeName(finfo->prorettype, zeroAsOpaque);
appendPQExpBuffer(q, "CREATE FUNCTION %s ", funcsig);
! appendPQExpBuffer(q, "RETURNS %s%s\n%s\nLANGUAGE %s",
(proretset[0] == 't') ? "SETOF " : "",
! rettypename,
! asPart->data,
! fmtId(lanname));
!
free(rettypename);
if (provolatile[0] != PROVOLATILE_VOLATILE)
{
if (provolatile[0] == PROVOLATILE_IMMUTABLE)
--- 6775,6786
rettypename = getFormattedTypeName(finfo->prorettype, zeroAsOpaque);
appendPQExpBuffer(q, "CREATE FUNCTION %s ", funcsig);
! appendPQExpBuffer(q, "RETURNS %s%s",
(proretset[0] == 't') ? "SETOF " : "",
! rettypename);
free(rettypename);
+ appendPQExpBuffer(q, "\nLANGUAGE %s", fmtId(lanname));
if (provolatile[0] != PROVOLATILE_VOLATILE)
{
if (provolatile[0] == PROVOLATILE_IMMUTABLE)
***
*** 6850,6856 dumpFunc(Archive *fout, FuncInfo *finfo)
appendStringLiteralAH(q, pos, fout);
}
! appendPQExpBuffer(q, ";\n");
ArchiveEntry(fout, finfo->dobj.catId, finfo->dobj.dumpId,
funcsig_tag,
--- 6848,6854
appendStringLiteralAH(q, pos, fout);
}
! appendPQExpBuffer(q, "\n%s;\n", asPart->data);
ArchiveEntry(fout, finfo->dobj.catId, finfo->dobj.dumpId,
funcsig_tag,
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Better formatting of functions in pg_dump
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes: >> Why the random switching between newline-before and newline-after >> styles? Please be consistent. > I thought they were all "after". On second glance, they still seem > all after? Oh, my mistake, I had failed to see that the patch was getting rid of newline-before style in this function. I think you might have gone a bit overboard on adding whitespace, but the previous objection is nonsense, sorry. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Better formatting of functions in pg_dump
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 >> Attached patch puts the "metadata" about a function, especially the >> language name, at the top of the CREATE FUNCTION statement, above the >> possibly long, multi-line function definition. > Why the random switching between newline-before and newline-after > styles? Please be consistent. I thought they were all "after". On second glance, they still seem all after? - -- Greg Sabino Mullane [EMAIL PROTECTED] End Point Corporation PGP Key: 0x14964AC8 200806122044 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkhRww0ACgkQvJuQZxSWSshuQwCfYBjBLOVfJziHcyHRM4CNfCaY gncAoK+CehREYJQdvAXfizZIPjZog4c6 =A+aR -END PGP SIGNATURE- -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Better formatting of functions in pg_dump
Greg Sabino Mullane <[EMAIL PROTECTED]> writes: > Attached patch puts the "metadata" about a function, especially the > language name, at the top of the CREATE FUNCTION statement, above the > possibly long, multi-line function definition. Why the random switching between newline-before and newline-after styles? Please be consistent. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] Better formatting of functions in pg_dump
Attached patch puts the "metadata" about a function, especially the
language name, at the top of the CREATE FUNCTION statement, above the
possibly long, multi-line function definition.
--
Greg Sabino Mullane
Index: pg_dump.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/pg_dump/pg_dump.c,v
retrieving revision 1.492
diff -c -r1.492 pg_dump.c
*** pg_dump.c 16 May 2008 23:36:05 - 1.492
--- pg_dump.c 12 Jun 2008 13:07:28 -
***
*** 6775,6784
rettypename = getFormattedTypeName(finfo->prorettype, zeroAsOpaque);
appendPQExpBuffer(q, "CREATE FUNCTION %s ", funcsig);
! appendPQExpBuffer(q, "RETURNS %s%s\n%s\nLANGUAGE %s",
(proretset[0] == 't') ? "SETOF " : "",
rettypename,
- asPart->data,
fmtId(lanname));
free(rettypename);
--- 6775,6783
rettypename = getFormattedTypeName(finfo->prorettype, zeroAsOpaque);
appendPQExpBuffer(q, "CREATE FUNCTION %s ", funcsig);
! appendPQExpBuffer(q, "RETURNS %s%s\nLANGUAGE %s\n",
(proretset[0] == 't') ? "SETOF " : "",
rettypename,
fmtId(lanname));
free(rettypename);
***
*** 6786,6794
if (provolatile[0] != PROVOLATILE_VOLATILE)
{
if (provolatile[0] == PROVOLATILE_IMMUTABLE)
! appendPQExpBuffer(q, " IMMUTABLE");
else if (provolatile[0] == PROVOLATILE_STABLE)
! appendPQExpBuffer(q, " STABLE");
else if (provolatile[0] != PROVOLATILE_VOLATILE)
{
write_msg(NULL, "unrecognized provolatile value for function \"%s\"\n",
--- 6785,6793
if (provolatile[0] != PROVOLATILE_VOLATILE)
{
if (provolatile[0] == PROVOLATILE_IMMUTABLE)
! appendPQExpBuffer(q, "IMMUTABLE\n");
else if (provolatile[0] == PROVOLATILE_STABLE)
! appendPQExpBuffer(q, "STABLE\n");
else if (provolatile[0] != PROVOLATILE_VOLATILE)
{
write_msg(NULL, "unrecognized provolatile value for function \"%s\"\n",
***
*** 6798,6807
}
if (proisstrict[0] == 't')
! appendPQExpBuffer(q, " STRICT");
if (prosecdef[0] == 't')
! appendPQExpBuffer(q, " SECURITY DEFINER");
/*
* COST and ROWS are emitted only if present and not default, so as not to
--- 6797,6806
}
if (proisstrict[0] == 't')
! appendPQExpBuffer(q, "STRICT\n");
if (prosecdef[0] == 't')
! appendPQExpBuffer(q, "SECURITY DEFINER\n");
/*
* COST and ROWS are emitted only if present and not default, so as not to
***
*** 6814,6831
{
/* default cost is 1 */
if (strcmp(procost, "1") != 0)
! appendPQExpBuffer(q, " COST %s", procost);
}
else
{
/* default cost is 100 */
if (strcmp(procost, "100") != 0)
! appendPQExpBuffer(q, " COST %s", procost);
}
}
if (proretset[0] == 't' &&
strcmp(prorows, "0") != 0 && strcmp(prorows, "1000") != 0)
! appendPQExpBuffer(q, " ROWS %s", prorows);
for (i = 0; i < nconfigitems; i++)
{
--- 6813,6830
{
/* default cost is 1 */
if (strcmp(procost, "1") != 0)
! appendPQExpBuffer(q, "COST %s\n", procost);
}
else
{
/* default cost is 100 */
if (strcmp(procost, "100") != 0)
! appendPQExpBuffer(q, " COST %s\n", procost);
}
}
if (proretset[0] == 't' &&
strcmp(prorows, "0") != 0 && strcmp(prorows, "1000") != 0)
! appendPQExpBuffer(q, " ROWS %s\n", prorows);
for (i = 0; i < nconfigitems; i++)
{
***
*** 6837,6843
if (pos == NULL)
continue;
*pos++ = '\0';
! appendPQExpBuffer(q, "\nSET %s TO ", fmtId(configitem));
/*
* Some GUC variable names are 'LIST' type and hence must not be
--- 6836,6842
if (pos == NULL)
continue;
*pos++ = '\0';
! appendPQExpBuffer(q, "SET %s TO ", fmtId(configitem));
/*
* Some GUC variable names are 'LIST' type and hence must not be
***
*** 6848,6856
appendPQExpBuffer(q, "%s", pos);
else
appendStringLiteralAH(q, pos, fout);
}
! appendPQExpBuffer(q, ";\n");
ArchiveEntry(fout, finfo->dobj.catId, finfo->dobj.dumpId,
funcsig_tag,
--- 6847,6857
appendPQExpBuffer(q, "%s", pos);
else
appendStringLiteralAH(q, pos, fout);
+
+ appendPQExpBuffer(q, "\n");
}
! appendPQExpBuffer(q, "%s;\n", asPart->data);
ArchiveEntry(fout, finfo->dobj.catId, finfo->dobj.dumpId,
funcsig_tag,
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
