+ 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: subscri
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
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I'm sure there are other ways to phase out OIDs in dumps.
Okay, fair enough -- I'll submit a patch to change this.
-Neil
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
If I want to develop a portable application or I want to port an
application, then I am of course only going to use portable constructs,
that is, tables and views, and possibly sequences. I'm not talking theory
here -- I've actually done it and made several changes to pg_dump along
the way to make
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> If that really was the error you got, your patch couldn't have
> fixed it since it didn't change anything that has something to do
> with it.
I entirely concur with Kurt's observation.
My bet is you got the "no space left on device" failure because you we
creating template1 database in
/export/home/tbaden/posttemp/postgresql-7.4/src/test/regress/./tmp_check/data/b+ase/1...
FATAL: could not create semaphores: No space left on device
DETAIL: Failed system call was semget(1, 17, 03600).
HINT: This error does *not* mean that you have run out of disk
--- Tom Lane <[EMAIL PROTECTED]> wrote:
> Kurt Roeckx <[EMAIL PROTECTED]> writes:
> > He seems to have changed this too:
> > - typedef uint32 IpcMemoryKey;
> > + typedef size_t IpcMemoryKey;
> > That really should be a key_t.
>
> Yeah, I made it key_t in CVS tip. I'm just
> wondering what this co
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Also, I think we have to have a SET before every CREATE TABLE.
No, only when the value changes from last time. This is not rocket
science, it's the way pg_dump handles SETs already.
regards, tom lane
---
Peter Eisentraut wrote:
> Neil Conway writes:
>
> > I'm really not sure we do: the SQL produced by pg_dump was totally
> > non-portable before,
>
> Significant effort has been invested to make pg_dump output portable, and
> I've not had any problems with it last time I tried it. Please explain
>
Applied ot 7.4.1 now. Thanks.
---
Christopher Kings-Lynne wrote:
> Did you commit to 7.4.1 too Bruce?
>
> Chris
>
> Bruce Momjian wrote:
>
> > Patch applied. Thanks.
> >
> > -
Peter Eisentraut wrote:
> If I want to develop a portable application or I want to port an
> application, then I am of course only going to use portable constructs,
> that is, tables and views, and possibly sequences. I'm not talking theory
> here -- I've actually done it and made several changes
Christopher Kings-Lynne writes:
> > Significant effort has been invested to make pg_dump output portable, and
> > I've not had any problems with it last time I tried it. Please explain
> > why you think it's "totally" non-portable.
>
> Functions, indexes, operators, types, aggregates, users, grou
On Mon, 01 Dec 2003 13:32:10 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
>Manfred Koizar <[EMAIL PROTECTED]> writes:
>> comparetup_index() compares two IndexTuples. The structure
>> IndexTupleData consists basically of not much more than an ItemPointer,
>> and the patch is not much more than adding
13 matches
Mail list logo
