Thom Brown writes:
> On 29 August 2010 22:21, Tom Lane wrote:
>> What your changes seem to
>> accomplish is to take the and constructs
>> outside any , but what is the point of that?
> Well, those can be in their own container too, although I don't
> think that's an issue.
> But I shalln't p
On 29 August 2010 22:21, Tom Lane wrote:
> Thom Brown writes:
>> On 29 August 2010 21:31, Tom Lane wrote:
>>> Ummm ... this seems to be almost entirely pointless whitespace changes.
>>> Sure you attached the right diff?
>
>> Yes, the whitespace changes you're seeing are because I closed the
>>
Thom Brown writes:
> On 29 August 2010 21:31, Tom Lane wrote:
>> Ummm ... this seems to be almost entirely pointless whitespace changes.
>> Sure you attached the right diff?
> Yes, the whitespace changes you're seeing are because I closed the
> tag early, then re-opened it again for the next pa
On 29 August 2010 21:31, Tom Lane wrote:
> Thom Brown writes:
>> On 28 August 2010 19:50, Thom Brown wrote:
>>> On 28 August 2010 19:47, Thom Brown wrote:
>> On 28 August 2010 15:29, Thom Brown wrote:
I attach a patch which fixes a few layout and markup issues, and also
a bit of tidy
Thom Brown writes:
> On 28 August 2010 19:50, Thom Brown wrote:
>> On 28 August 2010 19:47, Thom Brown wrote:
> On 28 August 2010 15:29, Thom Brown wrote:
>>> I attach a patch which fixes a few layout and markup issues, and also
>>> a bit of tidying up.
> Okay, reattached and tested this time.
On 29 August 2010 20:24, Thom Brown wrote:
> On 29 August 2010 20:12, Peter Eisentraut wrote:
>> On fre, 2010-08-27 at 21:57 +0100, Thom Brown wrote:
>>> I've also noticed that a lot of the contents are indented as
>>> part of the markup, but when output in HTML, each space it recreated
>>> as i
Thom Brown wrote:
> Okay, I've made a couple other changes, but if it's not working
> now, I don't think it's supported. This page suggests that
> box-shadow isn't yet supported by KHTML:
> http://www.legendscrolls.co.uk/webstandards/khtml
No shadows in Konqueror.
> I've just tested it in O
On 29 August 2010 20:12, Peter Eisentraut wrote:
> On fre, 2010-08-27 at 21:57 +0100, Thom Brown wrote:
>> I've also noticed that a lot of the contents are indented as
>> part of the markup, but when output in HTML, each space it recreated
>> as it ends up in either or tags.
>>
>> contents see
On 29 August 2010 19:39, Kevin Grittner wrote:
> Thom Brown wrote:
>
>> And Kevin, I made the shadows a bit lighter in this version and
>> used the beige notes box.
>
> For my taste, that's perfect. (Now there's the trivial matter of
> making everyone else happy. ;-) )
>
> The rounded corners a
Thom Brown wrote:
> And Kevin, I made the shadows a bit lighter in this version and
> used the beige notes box.
For my taste, that's perfect. (Now there's the trivial matter of
making everyone else happy. ;-) )
The rounded corners and shadows aren't showing up in Konqueror, but
everything
Thom Brown wrote:
> Kevin Grittner wrote:
>> The rounded corners and shadows aren't showing up in Konqueror
> Okay, it appears there's also a KHTML engine setting for pre-CSS3
> support. I've added that in now for rounded corners and shadows.
> Any different?
Konqueror now shows rounded co
On 29 August 2010 20:02, Kevin Grittner wrote:
> Thom Brown wrote:
>> Kevin Grittner wrote:
>
>>> The rounded corners and shadows aren't showing up in Konqueror
>
>> Okay, it appears there's also a KHTML engine setting for pre-CSS3
>> support. I've added that in now for rounded corners and shad
On fre, 2010-08-27 at 19:56 +0100, Thom Brown wrote:
> E.g.:
>
> variance( class="parameter">expression)
>
> vs
>
> stddev_samp( class="parameter">expression)
>
> Which way is correct?
"Correct" is a strong word in such matters, but I prefer the latter
version.
--
Sent via pgsql-docs mailin
On fre, 2010-08-27 at 21:57 +0100, Thom Brown wrote:
> I've also noticed that a lot of the contents are indented as
> part of the markup, but when output in HTML, each space it recreated
> as it ends up in either or tags.
>
> contents seem to have been intentionally entered so
> that they brea
On 29 August 2010 17:46, Kevin Grittner wrote:
> Thom Brown wrote:
>
>> The only change is the addition of very light shadowing (for Dave
>> and Kevin)
>
> Sorry for sounding picky, but can the shadowing be even lighter? It
> seems a tad heavy next to the light gray in the boxes.
Okay, I've sto
"Kevin Grittner" writes:
> Thom Brown wrote:
>> http://www.flickr.com/photos/dark_ixion/4937010683/sizes/o/
> For me, that's the easiest to read so far. With a lot of the other
> distractions cleaned up, I wonder if it's worth throwing another
> version up with subtle shadows on the boxes whic
Tom Lane wrote:
> The yellow "note" boxes still strike me as too eye-grabbing for
> their purpose. Otherwise this version seems nice.
How about a color which still differentiates these without being
quite so bold -- like Beige (#F5F5DC)?
For an example, see:
http://en.wikipedia.org/wiki/B
On 29 August 2010 17:28, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Thom Brown wrote:
>>> http://www.flickr.com/photos/dark_ixion/4937010683/sizes/o/
>
>> For me, that's the easiest to read so far. With a lot of the other
>> distractions cleaned up, I wonder if it's worth throwing another
>>
Thom Brown wrote:
> The only change is the addition of very light shadowing (for Dave
> and Kevin)
Sorry for sounding picky, but can the shadowing be even lighter? It
seems a tad heavy next to the light gray in the boxes.
-Kevin
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.o
Thom Brown wrote:
> Kevin Grittner wrote:
>> You find examples like this:
>>
>>
>>
>> void qsort
>>void *dataptr[]
>>int left
>>int right
>>int (* comp)
>> void *, void *
>>
>>
>>
>
> But that page also says "Using FuncSynopsis for languages that are
> unrelated to C
On 08/29/2010 03:56 AM, Thom Brown wrote:
> Okay, as per Robert's suggestion, I've changed all
> example/definition/synopsis boxes to grey, and followed Dave's
> suggestion of restoring borders and making the default text colour
> black for all boxed content. Bear in mind the rubbish screenshot ap
On 29 August 2010 16:21, Kevin Grittner wrote:
> Alvaro Herrera wrote:
>> Excerpts from Thom Brown's message:
>
>>> variance(>> class="parameter">expression)
>>>
>>> vs
>>>
>>> stddev_samp(>> class="parameter">expression)
>>>
>>> Which way is correct?
>>
>> The latter I think -- see
>> http://www
Thom Brown wrote:
> Okay, as per Robert's suggestion, I've changed all
> example/definition/synopsis boxes to grey, and followed Dave's
> suggestion of restoring borders and making the default text colour
> black for all boxed content. Bear in mind the rubbish screenshot
> app I'm using heavily
Alvaro Herrera wrote:
> Excerpts from Thom Brown's message:
>> variance(> class="parameter">expression)
>>
>> vs
>>
>> stddev_samp(> class="parameter">expression)
>>
>> Which way is correct?
>
> The latter I think -- see
> http://www.docbook.org/tdg/en/html/function.html
> (but perhaps searc
Dmitriy Igrishin writes:
> The description of PQprepare() of libpq
> (http://www.postgresql.org/docs/9.0/static/libpq-exec.html)
> says:
> (But PQprepare is more flexible since it does not require parameter
> types to be pre-specified.)
> But the description of PREPARE
> (http://www.postgresql.o
On Sat, Aug 28, 2010 at 3:53 PM, Thom Brown wrote:
> blue boxes - definitions
> grey boxes - examples, output etc
> red boxes - warnings, cautions
> yellow boxes - notes
I think yellow notes and red warnings are good, but I wonder if
definitions should get the same markup as examples, output, etc
On Sat, Aug 28, 2010 at 9:08 PM, Thom Brown wrote:
>
> > Are the boxes really that distracting? How about if I remove the
> > border and just have a light background? The problem with relying on
> > font difference is that it's not the same on every platform, hence why
> > this all started.
> >
On 29 August 2010 08:39, Dave Page wrote:
> On Sat, Aug 28, 2010 at 9:08 PM, Thom Brown wrote:
>>
>> > Are the boxes really that distracting? How about if I remove the
>> > border and just have a light background? The problem with relying on
>> > font difference is that it's not the same on eve
On 29 August 2010 15:35, Tom Lane wrote:
> Thom Brown writes:
>> I notice that the 9.0 docs page for CREATE TRIGGER doesn't indicate
>> column-level syntax in the synopsis:
>> http://www.postgresql.org/docs/9.0/static/sql-createtrigger.html
>
> My recollection is that we did it that way deliberat
Thom Brown writes:
> I notice that the 9.0 docs page for CREATE TRIGGER doesn't indicate
> column-level syntax in the synopsis:
> http://www.postgresql.org/docs/9.0/static/sql-createtrigger.html
My recollection is that we did it that way deliberately. The originally
submitted patch tried to expl
I notice that the 9.0 docs page for CREATE TRIGGER doesn't indicate
column-level syntax in the synopsis:
http://www.postgresql.org/docs/9.0/static/sql-createtrigger.html
It does detail the additional syntax required for specifying a column
in the "event" parameter detail, but shouldn't this also b
Hey all,
The description of PQprepare() of libpq
(http://www.postgresql.org/docs/9.0/static/libpq-exec.html)
says:
(But PQprepare is more flexible since it does not require parameter
types to be pre-specified.)
But the description of PREPARE
(http://www.postgresql.org/docs/9.0/static/sql-prepare
32 matches
Mail list logo
