Peter Eisentraut writes:
> Good question. I guess we could keep the original name "... Modules"
> for that chapter.
Those are a kind of server application in my mind, I think we want to
keep using “module” to mean the shared library file we load at runtime,
be it a .so, a .dylib or a .dll.
That
On ons, 2012-04-11 at 22:10 +0100, Thom Brown wrote:
> On 11 April 2012 21:58, Peter Eisentraut wrote:
> > On ons, 2012-04-11 at 21:42 +0100, Thom Brown wrote:
> >> Could you clarify what you're defining to be a client application and
> >> a server application? This could be confusing as we alrea
On 11 April 2012 21:58, Peter Eisentraut wrote:
> On ons, 2012-04-11 at 21:42 +0100, Thom Brown wrote:
>> Could you clarify what you're defining to be a client application and
>> a server application? This could be confusing as we already have
>> sections under Reference called "PostgreSQL Client
On ons, 2012-04-11 at 21:42 +0100, Thom Brown wrote:
> > G. Additional Supplied Applications
> >
> > with two subsections Client and Server Applications, and one refentry
> > per application. That would end up looking much like the SPI chapter.
>
> Could you clarify what you're defining to be a c
On 11 April 2012 21:29, Peter Eisentraut wrote:
> On ons, 2012-04-04 at 21:53 +0300, Peter Eisentraut wrote:
>> I think it would be useful to split this up into three sections:
>
>> F.1. Extensions
>> F.2. Client Applications
>> F.3. Server Applications
>
>> where the first looks like now and the
On ons, 2012-04-04 at 21:53 +0300, Peter Eisentraut wrote:
> I think it would be useful to split this up into three sections:
> F.1. Extensions
> F.2. Client Applications
> F.3. Server Applications
> where the first looks like now and the other two contain the refentry
> pages.
> We could also c
On Wed, Apr 4, 2012 at 4:10 PM, Thom Brown wrote:
> +1 to anything that separates these out. Cramming them into one list
> like we currently have is confusing.
+1 as well.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mai
On 4 April 2012 19:53, Peter Eisentraut wrote:
> ... would be really nice to have. Especially pgbench and pg_upgrade for
> me, but it would be useful to have man pages for everything.
>
> Unfortunately, we can't just replace the sect1's in in Appendix F [0]
> with refentry's, because the content
On ons, 2012-04-04 at 16:29 -0300, Alvaro Herrera wrote:
> > Unfortunately, we can't just replace the sect1's in in Appendix F [0]
> > with refentry's, because the content model of DocBook doesn't allow
> > that. (You can't have a mixed sequence of sect1 and refentry, only one
> > or the other.)
>
Excerpts from Peter Eisentraut's message of mié abr 04 15:53:20 -0300 2012:
> ... would be really nice to have. Especially pgbench and pg_upgrade for
> me, but it would be useful to have man pages for everything.
>
> Unfortunately, we can't just replace the sect1's in in Appendix F [0]
> with re
... would be really nice to have. Especially pgbench and pg_upgrade for
me, but it would be useful to have man pages for everything.
Unfortunately, we can't just replace the sect1's in in Appendix F [0]
with refentry's, because the content model of DocBook doesn't allow
that. (You can't have a m
11 matches
Mail list logo
