On 02/27/2012 03:39 PM, Tom Lane wrote:
Greg Smith writes:
Here are some Debian/Ubuntu platforms that all run into the other problem:
Ubuntu 9.04, openjade 1.4devel1-19: flow error
Debian Squeeze, openjade 1.4devel1-19 : flow error
I always assumed that the reason this didn't work, but the
Greg Smith writes:
> Here are some Debian/Ubuntu platforms that all run into the other problem:
> Ubuntu 9.04, openjade 1.4devel1-19: flow error
> Debian Squeeze, openjade 1.4devel1-19 : flow error
> I always assumed that the reason this didn't work, but the Fedoras did,
> was because of a diff
Greg Smith writes:
> I just tried building postgres-US.pdf on a RHEL-derived system,
> Scientific Linux 6 using openjade-1.3.2-36.el6. That gave me lots of
> "Overfull hbox" errors, then died like this:
> ! pdfTeX error (ext4): \pdfendlink ended up in different nesting level
> than \pdfstartl
On Mon, February 27, 2012 18:30, Magnus Hagander wrote:
>>
does that work for others, or did we break something globally in it?
>>>
FWIW: I build A4 pdf's for HEAD often (say, weekly), on centos 5; it has always
worked this last
year or so (I did tweak tex (?) parameters, long ago).
I built
On 02/27/2012 12:22 PM, Tom Lane wrote:
FWIW, all the recent reports of this seem to be on Ubuntu or Debian.
Don't know if that means few of us use Fedora or if it means Fedora has
fixed this.
I just tried building postgres-US.pdf on a RHEL-derived system,
Scientific Linux 6 using openjade-1.3
On Mon, Feb 27, 2012 at 18:28, Magnus Hagander wrote:
> On Mon, Feb 27, 2012 at 18:22, Tom Lane wrote:
>> Magnus Hagander writes:
>>> On Mon, Feb 27, 2012 at 18:00, Tom Lane wrote:
Something else to keep in mind is that PDF-format docs are not terribly
forgiving of wide tables --- hav
Magnus Hagander writes:
> On Mon, Feb 27, 2012 at 18:22, Tom Lane wrote:
>> FWIW, I built all the back-branch versions in both US and A4 formats
>> last week on Fedora 16. Don't recall trying HEAD though.
> I only tried HEAD. Trying 9.1 now, and I get the same crash there. Can
> you (or someone
On Mon, Feb 27, 2012 at 18:22, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Feb 27, 2012 at 18:00, Tom Lane wrote:
>>> Something else to keep in mind is that PDF-format docs are not terribly
>>> forgiving of wide tables --- have you looked at what these look like in
>>> PDF?
>
>> I have
Magnus Hagander writes:
> On Mon, Feb 27, 2012 at 18:00, Tom Lane wrote:
>> Something else to keep in mind is that PDF-format docs are not terribly
>> forgiving of wide tables --- have you looked at what these look like in
>> PDF?
> I have not, and I can't seem to build them:
> openjade -D . -D
On Mon, Feb 27, 2012 at 18:00, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Feb 27, 2012 at 11:32 AM, Magnus Hagander
>> wrote:
>>> On Mon, Feb 27, 2012 at 14:36, Robert Haas wrote:
Yeah, that's one thing I don't like about what you actually did,
either - it made some of the tabl
Robert Haas writes:
> On Mon, Feb 27, 2012 at 11:32 AM, Magnus Hagander wrote:
>> On Mon, Feb 27, 2012 at 14:36, Robert Haas wrote:
>>> Yeah, that's one thing I don't like about what you actually did,
>>> either - it made some of the tables much wider.
>> Uh, can you give me an example of one?
On Mon, Feb 27, 2012 at 11:32 AM, Magnus Hagander wrote:
> On Mon, Feb 27, 2012 at 14:36, Robert Haas wrote:
>> On Mon, Feb 27, 2012 at 5:22 AM, Magnus Hagander wrote:
>>> The problem with a separate column is that it makes the table very
>>> wide (some of those functions have very long name).
>
On Mon, Feb 27, 2012 at 14:36, Robert Haas wrote:
> On Mon, Feb 27, 2012 at 5:22 AM, Magnus Hagander wrote:
>> The problem with a separate column is that it makes the table very
>> wide (some of those functions have very long name).
>
> Yeah, that's one thing I don't like about what you actually
On Mon, Feb 27, 2012 at 5:22 AM, Magnus Hagander wrote:
> The problem with a separate column is that it makes the table very
> wide (some of those functions have very long name).
Yeah, that's one thing I don't like about what you actually did,
either - it made some of the tables much wider.
>> s
On Mon, Feb 27, 2012 at 04:44, Robert Haas wrote:
> On Sat, Feb 25, 2012 at 9:33 AM, Magnus Hagander wrote:
>> On Mon, Jan 16, 2012 at 02:03, Greg Smith wrote:
>>> On 01/15/2012 12:20 PM, Tom Lane wrote:
Please follow the style already used for system catalogs; ie I think
there sh
On Sat, Feb 25, 2012 at 9:33 AM, Magnus Hagander wrote:
> On Mon, Jan 16, 2012 at 02:03, Greg Smith wrote:
>> On 01/15/2012 12:20 PM, Tom Lane wrote:
>>>
>>> Please follow the style already used for system catalogs; ie I think
>>> there should be a summary table with one entry per view, and then
On Mon, Jan 16, 2012 at 02:03, Greg Smith wrote:
> On 01/15/2012 12:20 PM, Tom Lane wrote:
>>
>> Please follow the style already used for system catalogs; ie I think
>> there should be a summary table with one entry per view, and then a
>> separate description and table-of-columns for each view.
>
On Wed, Feb 8, 2012 at 17:13, Bruce Momjian wrote:
> On Tue, Feb 07, 2012 at 11:29:12PM -0500, Tom Lane wrote:
>> Bruce Momjian writes:
>> > How do people feel about pulling text out of the SGML docs and loading
>> > it into the database as table and column comments?
>>
>> I'm not thrilled by tha
On Tue, Feb 07, 2012 at 11:29:12PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > How do people feel about pulling text out of the SGML docs and loading
> > it into the database as table and column comments?
>
> I'm not thrilled by that proposal. The length limits on comments are
> very much
On Feb 8, 2012 5:32 AM, "Tom Lane" wrote:
>
> Bruce Momjian writes:
> > How do people feel about pulling text out of the SGML docs and loading
> > it into the database as table and column comments?
>
> I'm not thrilled by that proposal. The length limits on comments are
> very much shorter than
Bruce Momjian writes:
> How do people feel about pulling text out of the SGML docs and loading
> it into the database as table and column comments?
I'm not thrilled by that proposal. The length limits on comments are
very much shorter than what is sensible to use in catalogs.sgml (at
least if yo
On Mon, Jan 16, 2012 at 01:01:50PM -0300, Alvaro Herrera wrote:
>
>
> Bruce had a patch to turn SGML descriptions of system view into comments
> via some Perl program or something. He posted it many moons ago and I
> haven't seen an updated version. Bruce, do you have something to say on
> this
On Mon, Jan 16, 2012 at 19:41, Peter Eisentraut wrote:
> On sön, 2012-01-15 at 12:20 -0500, Tom Lane wrote:
>> Magnus Hagander writes:
>> > Right now we have a single table on
>> > http://www.postgresql.org/docs/devel/static/monitoring-stats.html#MONITORING-STATS-VIEWS
>> > that lists all our sta
On sön, 2012-01-15 at 12:20 -0500, Tom Lane wrote:
> Magnus Hagander writes:
> > Right now we have a single table on
> > http://www.postgresql.org/docs/devel/static/monitoring-stats.html#MONITORING-STATS-VIEWS
> > that lists all our statistics views ...
> > I'd like to turn that into one table for
Bruce had a patch to turn SGML descriptions of system view into comments
via some Perl program or something. He posted it many moons ago and I
haven't seen an updated version. Bruce, do you have something to say on
this topic?
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
P
On 01/15/2012 12:20 PM, Tom Lane wrote:
Please follow the style already used for system catalogs; ie I think
there should be a summary table with one entry per view, and then a
separate description and table-of-columns for each view.
Yes, that's a perfect precedent. I think the easiest path fo
Magnus Hagander writes:
> Right now we have a single table on
> http://www.postgresql.org/docs/devel/static/monitoring-stats.html#MONITORING-STATS-VIEWS
> that lists all our statistics views ...
> I'd like to turn that into one table for each view,
Please follow the style already used for system
On Sun, Jan 15, 2012 at 10:35, Greg Smith wrote:
> On 01/15/2012 03:51 AM, Magnus Hagander wrote:
>>
>> I'd like to turn that into one table for each view, with two columns,
>> one being the name the other one being the description. That'll also
>> make it possible to expand on the descriptions wi
On 01/15/2012 03:51 AM, Magnus Hagander wrote:
I'd like to turn that into one table for each view, with two columns,
one being the name the other one being the description. That'll also
make it possible to expand on the descriptions without making it
completley unreadable, should we want to.
Sc
Right now we have a single table on
http://www.postgresql.org/docs/devel/static/monitoring-stats.html#MONITORING-STATS-VIEWS
that lists all our statistics views. It makes for difficult to parse
descriptions like "One row only, showing cluster-wide statistics from
the background writer: number of sc
30 matches
Mail list logo
