http://www.postgresql.org/docs/9.0/interactive/typeconv-query.html
example shows:
CREATE TABLE vv (v character(20));
INSERT INTO vv SELECT 'abc' || 'def';
SELECT v, length(v) FROM vv;
v | length
--+
abcdef | 20
(1 row)
but m
Peter Eisentraut wrote:
> On s?n, 2011-03-20 at 13:32 -0700, Josh Berkus wrote:
> > This page:
> >
> > http://www.postgresql.org/docs/8.3/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHERE
> >
> > has the following text:
> >
> > The value is treated as a strftime pattern, so %-escap
Robert Haas wrote:
> On Sat, Mar 12, 2011 at 3:57 PM, Tom Lane wrote:
> > Peter Eisentraut writes:
> >> On l?r, 2011-03-12 at 09:13 -0500, Bruce Momjian wrote:
> >>> OK, it is not something worthwhile, or just something you don't have
> >>> time for. ?If the later, can you give us a hint on how t
Peter Eisentraut wrote:
> On fre, 2011-01-28 at 12:11 -0500, Tom Lane wrote:
> > In my build, the entire contrib manual is potentially interdependent,
> > because the sub-sections of Appendix F don't start new pages. This
> > seems bad. What is even more curious is that it looks like the function
Bruce Momjian wrote:
> > So I guess I'm back agreeing with you. Basically, it seems like we
> > ought to use if it's being used as a value that the user
> > might want to supply (e.g. "if you set this parameter to 0, then no
> > statements will be logged). It shouldn't use if it's just
> > bein
Did we want to do any more on the issue of using for numbers
in our docs? The February thread is here:
http://archives.postgresql.org/pgsql-docs/2011-02/msg00028.php
While the applied patch removed the 'literal' tag from some numbers, we
were not consistenly using 'literal' for constan
