Fix busted markup.
Evidently from commit 878fdcb843e087cc1cdeadc987d6ef55202ddd04.
Per buildfarm.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/d1479011744d80d80c669b5bd64dc32187f26c1e
Modified Files
--
doc/src/sgml/pgbench.sgml |4 ++--
1 file chan
Robert Haas writes:
> On Mon, Mar 2, 2015 at 2:38 PM, Tom Lane wrote:
>> The makefile changes in this do not look right to me. Files that are
>> meant to be shipped in the tarball should be removed by make
>> maintainer-clean, not an ordinary "make clean" which is what the committed
>> patch app
Also, it appears that the exprscan.h file doesn't actually
get (or need to be) generated here.
Indeed.
So I think we need something like the attached.
There is a $(RM) make macro usually defined as "rm -f", but it does not
seem to be used elsewhere.
--
Fabien.
--
Sent via pgsql-commi
On Mon, Mar 2, 2015 at 2:38 PM, Tom Lane wrote:
> Robert Haas writes:
>> pgbench: Add a real expression syntax to \set
>
> The makefile changes in this do not look right to me. Files that are
> meant to be shipped in the tarball should be removed by make
> maintainer-clean, not an ordinary "make
The makefile changes in this do not look right to me. Files that are
meant to be shipped in the tarball should be removed by make
maintainer-clean, not an ordinary "make clean" which is what the committed
patch appears to do. Otherwise, a tarball user without bison installed
would be cut off a
Robert Haas writes:
> pgbench: Add a real expression syntax to \set
The makefile changes in this do not look right to me. Files that are
meant to be shipped in the tarball should be removed by make
maintainer-clean, not an ordinary "make clean" which is what the committed
patch appears to do. O
pgbench: Add a real expression syntax to \set
Previously, you could do \set variable operand1 operator operand2, but
nothing more complicated. Now, you can \set variable expression, which
makes it much simpler to do multi-step calculations here. This also
adds support for the modulo operator (%)
Fix pg_dump handling of extension config tables
Since 9.1, we've provided extensions with a way to denote
"configuration" tables- tables created by an extension which the user
may modify. By marking these as "configuration" tables, the extension
is asking for the data in these tables to be pg_dum
Fix pg_dump handling of extension config tables
Since 9.1, we've provided extensions with a way to denote
"configuration" tables- tables created by an extension which the user
may modify. By marking these as "configuration" tables, the extension
is asking for the data in these tables to be pg_dum
Fix pg_dump handling of extension config tables
Since 9.1, we've provided extensions with a way to denote
"configuration" tables- tables created by an extension which the user
may modify. By marking these as "configuration" tables, the extension
is asking for the data in these tables to be pg_dum
Fix pg_dump handling of extension config tables
Since 9.1, we've provided extensions with a way to denote
"configuration" tables- tables created by an extension which the user
may modify. By marking these as "configuration" tables, the extension
is asking for the data in these tables to be pg_dum
Fix pg_dump handling of extension config tables
Since 9.1, we've provided extensions with a way to denote
"configuration" tables- tables created by an extension which the user
may modify. By marking these as "configuration" tables, the extension
is asking for the data in these tables to be pg_dum
12 matches
Mail list logo
