When selecting with the AT TIME ZONE or timezone function, the returned value
is not always a timestamp. This is inconsistent with the documentation.
To reproduce this problem, run these two queries.
SELECT now() AT TIME ZONE 'EST'
returns 2003-03-13 21:27:14.63401-05
SELECT now() AT TIME ZON
On Thu, 13 Mar 2003, Tom Lane wrote:
TL>regression=# create user z;
TL>CREATE USER
TL>regression=# create schema s;
TL>CREATE SCHEMA
TL>regression=# \c - z
TL>You are now connected as new user z.
TL>regression=> create table s.t (f1 int);
TL>ERROR: s: permission denied
TL>regression=>
TL>I'm not
A kind person on the pgsql-general list told me.
"This appears to be a simple typo in the pg_proc entry for the function.
The underlying C code thinks it is returning a timestamp without time
zone, but that's not what the pg_proc entry has.
You can fix this in an existing database by doing
UPDAT
In addition, I have upgraded to postgre 7.3.2 instead of postgre 7.3 and I get
the exact same output except that years are included in the interval.
It still returns an interval instead of a timestamp.
josh.
On March 13, 2003 10:12 pm, Joshua Moore-Oliva wrote:
> When selecting with the AT TI
When selecting with the AT TIME ZONE or timezone function, the returned value
is not always a timestamp. This is inconsistent with the documentation.
To reproduce this problem, run these two queries.
SELECT now() AT TIME ZONE 'EST'
returns 2003-03-13 21:27:14.63401-05
SELECT now() AT TIME ZONE
dmarin <[EMAIL PROTECTED]> writes:
> This query never returns:
> select log(93094::numeric/92908::numeric);
The attached patch against 7.3 seems to take care of the problem. You
should be able to apply it to 7.2, with possibly some tweaking (the code
needs to go into the loop in ln_var()).
I am
Oliver Elphick <[EMAIL PROTECTED]> writes:
> This is with -configure -enable-integer-datetime in 7.3.2, i386 Linux
> platform. Is anyone else seeing this? If so, does it happen without
> --enable-integer-datetime?
> junk=# select * from mt;
> v
> -
>
This is with -configure -enable-integer-datetime in 7.3.2, i386 Linux
platform. Is anyone else seeing this? If so, does it happen without
--enable-integer-datetime?
junk=# \d mt
Table "public.mt"
Column |Type | Modifiers
--
On Thu, 13 Mar 2003, Donald Fraser wrote:
> I have a question regarding transactions.
> When updating a row of a table PostgreSQL obtains a RowExclusive lock,
> which according to the docs means that no other transaction can obtain
> a RowExclusive lock on this row in the same table until the ex
I have a question regarding
transactions.
When updating a row of a table PostgreSQL obtains a
RowExclusive lock, which according to the docs means that no other transaction
can obtain a RowExclusive lock on this row in the same table until the
existing one is released. That seems fair enoug
Ok there is the context diff of my modification :
Bye
Laurent
---
*** postgresql-7.3.2/src/bin/pg_dump/pg_dump.c Fri Dec
27 18:10:55 2002
--- postgresql-7.3.2/src/bin/pg_dump/pg_dump.c.new Wed
Mar 5 12:12:32 2003
***
*** 601,606
--- 601,609
Andrew Koshelev <[EMAIL PROTECTED]> writes:
> As you can see, optimizer in earlier version of PostgreSQL skips
> unneeded data, but latest version doesn't.
CVS tip works the way you want it to. The behavior in 7.3.* is an
unfortunate side-effect of a quick-and-dirty bug fix. The less dirty
way t
Evgeny Duzhakow <[EMAIL PROTECTED]> writes:
> Now connect and try to create the table:
> testtables=# \c - fake
> You are now connected as new user fake.
> testtables=> create table qq(i int);
> CREATE TABLE
Sure. You need to revoke CREATE access on the public schema (not the
same thing as the
I have in subselect processing.
Example below:
create table users (uid serial primary key, uname text);
create table folders (fid serial primary key, fname text, uid int);
create view user_view as select u.uid, u.uname, (select count (*) from
folders where uid = u.uid) as nfolders from users u;
14 matches
Mail list logo
