Re: [PATCHES] Small documentation patch

2006-10-02 Thread Bruce Momjian

Patch applied.  Thanks.

---


Guillaume Lelarge wrote:
> Hi all,
> 
> This patch fixes a small typo in information_schema.sgml.
> 
> Regards.
> 
> 
> -- 
> Guillaume.
> 

> ? information_schema.patch
> Index: doc/src/sgml/information_schema.sgml
> ===
> RCS file: /projects/cvsroot/pgsql/doc/src/sgml/information_schema.sgml,v
> retrieving revision 1.27
> diff -u -3 -p -r1.27 information_schema.sgml
> --- doc/src/sgml/information_schema.sgml  5 Sep 2006 21:08:34 -   
> 1.27
> +++ doc/src/sgml/information_schema.sgml  2 Oct 2006 23:26:32 -
> @@ -5074,7 +5074,7 @@ ORDER BY c.ordinal_position;
>   
>  
>   
> -  view definition
> +  view_definition
>character_data
>
> Query expression defining the view (null if the view is not

> 
> ---(end of broadcast)---
> TIP 2: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


[PATCHES] Small documentation patch

2006-10-02 Thread Guillaume Lelarge
Hi all,

This patch fixes a small typo in information_schema.sgml.

Regards.


-- 
Guillaume.

? information_schema.patch
Index: doc/src/sgml/information_schema.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/information_schema.sgml,v
retrieving revision 1.27
diff -u -3 -p -r1.27 information_schema.sgml
--- doc/src/sgml/information_schema.sgml5 Sep 2006 21:08:34 -   
1.27
+++ doc/src/sgml/information_schema.sgml2 Oct 2006 23:26:32 -
@@ -5074,7 +5074,7 @@ ORDER BY c.ordinal_position;
  
 
  
-  view definition
+  view_definition
   character_data
   
Query expression defining the view (null if the view is not

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [PATCHES] Small documentation patch

2003-12-03 Thread David Fetter
On Wed, Dec 03, 2003 at 10:49:01AM -0500, Tom Lane wrote:
> 
>   SELECT 'epoch'::timestamp + '1070430858 seconds'::interval;
> 
> because it will produce a timestamp without time zone, thus
> effectively making the epoch be 1970-1-1 midnight local time.  But
> of course the correct Unix epoch is 1970-1-1 midnight GMT.  So
> correct code is

>   SELECT 'epoch'::timestamptz + '1070430858 seconds'::interval;
> 
> or you could use
> 
>   SELECT 'epoch'::timestamptz + 1070430858 * '1 second'::interval;

> which has the advantage that it works without weird concatenation
> pushups when the numeric value is coming from a variable.

Great!  I am not attached to any particular way of doing this, just as
long as some clue about converting UNIX timestamps into PostgreSQL
timestamps gets in there :)

Cheers,
D
-- 
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 510 893 6100cell: +1 415 235 3778

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [PATCHES] Small documentation patch

2003-12-03 Thread Tom Lane
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Whoops:
> SELECT 1070430858::abstime::timestamp;

Or you can do

  SELECT '1070430858'::int4::abstime::timestamp;

which helps expose the fact that you're really depending on the
int4-to-abstime binary equivalence.  This will certainly break in
2038...

The originally proposed documentation patch is flat wrong:

  SELECT 'epoch'::timestamp + '1070430858 seconds'::interval;

because it will produce a timestamp without time zone, thus effectively
making the epoch be 1970-1-1 midnight local time.  But of course the
correct Unix epoch is 1970-1-1 midnight GMT.  So correct code is

  SELECT 'epoch'::timestamptz + '1070430858 seconds'::interval;

or you could use

  SELECT 'epoch'::timestamptz + 1070430858 * '1 second'::interval;

which has the advantage that it works without weird concatenation
pushups when the numeric value is coming from a variable.

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])


Re: [PATCHES] Small documentation patch

2003-12-03 Thread Christopher Kings-Lynne

template1=# SELECT '1070430858'::abstime;
ERROR:  invalid input syntax for type abstime: "1070430858"
I agree its more stable :-). That's on HEAD.
Whoops:

SELECT 1070430858::abstime::timestamp;

Chris



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [PATCHES] Small documentation patch

2003-12-03 Thread David Fetter
On Wed, Dec 03, 2003 at 05:59:25PM +1100, Gavin Sherry wrote:
> On Wed, 3 Dec 2003, Christopher Kings-Lynne wrote:
> 
> >
> > > + SELECT 'epoch'::timestamp + '1070430858 seconds'::interval;
> > > + Result: 2003-12-03 
> > > 05:54:18
> > >   
> >
> > You could also go:
> >
> > SELECT '1070430858'::abstime;
> >
> > But your way is probably a bit more stable...dunno...
> 
> template1=# SELECT '1070430858'::abstime;
> ERROR:  invalid input syntax for type abstime: "1070430858"
> 
> I agree its more stable :-). That's on HEAD.
> 
> Gavin

I like "more stable."  "Clearer" is good, too :) :)

Cheers,
D
-- 
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 510 893 6100cell: +1 415 235 3778

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [PATCHES] Small documentation patch

2003-12-03 Thread Gavin Sherry
On Wed, 3 Dec 2003, Christopher Kings-Lynne wrote:

>
> > + SELECT 'epoch'::timestamp + '1070430858 seconds'::interval;
> > + Result: 2003-12-03 
> > 05:54:18
> >   
>
> You could also go:
>
> SELECT '1070430858'::abstime;
>
> But your way is probably a bit more stable...dunno...

template1=# SELECT '1070430858'::abstime;
ERROR:  invalid input syntax for type abstime: "1070430858"

I agree its more stable :-). That's on HEAD.

Gavin

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [PATCHES] Small documentation patch

2003-12-02 Thread Christopher Kings-Lynne

+ SELECT 'epoch'::timestamp + '1070430858 seconds'::interval;
+ Result: 2003-12-03 
05:54:18
  
You could also go:

SELECT '1070430858'::abstime;

But your way is probably a bit more stable...dunno...

Chris



---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


[PATCHES] Small documentation patch

2003-12-02 Thread David Fetter
Kind people,

This patch shows how to change UNIX timestamps into PostgreSQL
timestamps, and clarifies how PERFORM works in PL/PgSQL. :)

Cheers,
D
-- 
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 510 893 6100cell: +1 415 235 3778
Index: func.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/func.sgml,v
retrieving revision 1.180
diff -2 -c -r1.180 func.sgml
*** func.sgml   29 Nov 2003 19:51:37 -  1.180
--- func.sgml   3 Dec 2003 06:17:20 -
***
*** 5006,5009 
--- 5006,5018 
  SELECT EXTRACT(EPOCH FROM INTERVAL '5 days 3 hours');
  Result: 442800
+ 
+
+ To convert a UNIX timestamp (number of seconds since
+ 1970-01-01 00:00:00-00) into a timestamp, you can
+ write:
+
+ 
+ SELECT 'epoch'::timestamp + '1070430858 seconds'::interval;
+ Result: 2003-12-03 
05:54:18
  

Index: plpgsql.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/plpgsql.sgml,v
retrieving revision 1.32
diff -2 -c -r1.32 plpgsql.sgml
*** plpgsql.sgml30 Nov 2003 05:45:22 -  1.32
--- plpgsql.sgml3 Dec 2003 06:17:22 -
***
*** 1033,1036 
--- 1033,1050 
  
  
+ 
+ 
+  Another example, which returns true if user foo is in group bar:
+ 
+ PERFORM *
+ FROM 
+   pg_catalog.pg_user u
+ , pg_catalog.pg_group g
+ WHERE u.usesysid = ANY(g.grolist)
+ AND u.usename='foo'
+ AND g.groname='bar';
+ 
+ 
+ 
 
 

---(end of broadcast)---
TIP 8: explain analyze is your friend