Re: [SQL] definative way to place secs from epoc into timestamp

Just so I don't make a newb mistake I should use timestamptz not timestamp where the exact moment is important? My conversion which is not live yet is using timestamp as I did not clearly understand (but be very easy I hope to modify in my app that creates and moves the data just use timestamptz i

Re: [SQL] definative way to place secs from epoc into timestamp

Andrew - Supernews <[EMAIL PROTECTED]> writes: > On 2005-03-04, Bret Hughes <[EMAIL PROTECTED]> wrote: >>> (Why are you using timestamp without time zone anyway? For recording the >> >> Valid question. Because there is no reason to keep up with time zones > It's a common mistake to think that ju

Re: [SQL] definative way to place secs from epoc into timestamp

and the fact that I want the same value from the data base that I put into it. "same" in which sense? The same absolute point in time? Or the same point on a calendar? Obviously if the timezone doesn't change, then the two are equivalent; but which one is your application actually looking for? (I

Re: [SQL] definative way to place secs from epoc into timestamp

Unix time stamps, short (int) or long res, are always supposed to GMT based, as far as I know - I never seen anything different, except maybe in homebrew software. So it should be both calendar and P.I.T. And you wouldn't need the TZ storage if the date-number and number-> translation itself ta

[SQL] date - date returns integer?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Should date - date return type integer, not interval? /* [EMAIL PROTECTED]:5432/test =# */ SELECT ('2005-03-04'::timestamp - '2005-01-01'::date)::interval; ~ interval - -- ~ 62 days (1 row) /* [EMAIL PROTECTED]:5432/test =# */ SELECT ('2005-03-0

Re: [SQL] date - date returns integer?

On Fri, Mar 04, 2005 at 15:59:02 -0500, Andrew Hammond <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Should date - date return type integer, not interval? Yes. This is in the documentation. ---(end of broadcast)

[SQL] Simple delete takes hours

Hi there, I have a simple database: CREATE TABLE pwd_description ( id SERIALNOT NULL UNIQUE PRIMARY KEY, name varchar(50) NOT NULL ); CREATE TABLE pwd_name ( id SERIALNOT NULL UNIQUE PRIMARY KEY, description integer NOT NULL REFERENCES pwd_descri

Re: [SQL] Postgres performance

Hi, thanks a lot! you are rigth, but I did read your message ;) Yes, 1- I misconfigured PostgreSQL (I thought that was already configured in base to the released version - Fedora Core 3 64bit). 2- The bench is, clearly after your precisations, an MySQL tuned application tests. 3- I think the bench

[SQL] Problem with SQL_ASCII

I have a little problem in PostgreSQL 7.39 (and previous). Our database is in 'SQL_ASCII'-Format. When doing SQL-Selects all special Characters (e.g. äöüß, etc...) are ASCII encoded (sure they are). Is there any function to change the encoding to - let's say - LATIN1 (reverse function for to_ascii(

[SQL] truncating table permissions

I was expecting "truncate table " to truncate a table if I had delete permissions. This does not appear to be the case. Would someone confirm this for me, or let me know what I am doing wrong. -- Lyn ---(end of broadcast)--- TIP 2: you can ge

Re: [SQL] Postgres performance

Hi Richard, thank you for your apreciated answers!!! - start quote - Well, do you care whether your data is consistent or not? If not, you don't need transactions. - end quote - I don't require transaction because the query aren't complex and update a single tuple (in SELECT transactions are us

Re: [SQL] Simple delete takes hours

On Thu, 3 Mar 2005, Thomas Mueller wrote: > Hi there, > > I have a simple database: > > CREATE TABLE pwd_description ( >id SERIALNOT NULL UNIQUE PRIMARY KEY, >name varchar(50) NOT NULL > ); > > CREATE TABLE pwd_name ( >id SERIALNOT NULL UNIQUE PR

Re: [SQL] Postgres performance

I don't require transaction because the query aren't complex and update a single tuple (in SELECT transactions are useless) You mean, you have no foreign keys in your database ? In SELECT they are definitely useful (think select for update, isolation level serializable...) - start quote - Yo

Re: [SQL] Simple delete takes hours

Every time a row is removed from pwd_name, the ON DELETE CASCADE trigger will look in pwd_name_rev if there is a row to delete... Does it have an index on pwd_name_rev( rev_of ) ? If not you'll get a full table scan for every row deleted in pwd_name... On Thu, 03 Mar 2005 22:44:58 +0100, T

Re: [SQL] definative way to place secs from epoc into timestamp

On 2005-03-04, "Joel Fradkin" <[EMAIL PROTECTED]> wrote: > Just so I don't make a newb mistake I should use timestamptz not timestamp > where the exact moment is important? Yes. -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services ---(en

Re: [SQL] truncating table permissions

Lynwood Stewart wrote: I was expecting "truncate table " to truncate a table if I had delete permissions. This does not appear to be the case. Would someone confirm this for me, or let me know what I am doing wrong. This is the case. You are not doing anything wrong. There was a discussion

Re: [SQL] definative way to place secs from epoc into timestamp

On Fri, 2005-03-04 at 01:35, Michael Glaesemann wrote: > > On Mar 4, 2005, at 14:47, Bret Hughes wrote: > > > On Thu, 2005-03-03 at 14:58, Andrew - Supernews wrote: > >> (Why are you using timestamp without time zone anyway? For recording > >> the > >> time at which an event occurred that usage

Re: [SQL] date - date returns integer?

Andrew Hammond <[EMAIL PROTECTED]> writes: > Should date - date return type integer, not interval? If we made it return interval then there would be all sorts of timezone dependencies introduced (think about DST crossings) ... which is generally something you don't want to think about when doing d

Re: [SQL] truncating table permissions

"Lynwood Stewart" <[EMAIL PROTECTED]> writes: > I was expecting "truncate table " to truncate a table if I had > delete permissions. This does not appear to be the case. No, TRUNCATE is restricted to the table's owner, regardless of any grantable permissions. This was (ahem) inadequately docume