On Jan 11, 2009, at 8:16 PM, Jeff Davis wrote:
On Sun, 2009-01-11 at 17:13 -0600, Tim Hart wrote:
Would it be worthwhile to specify this in the documentation? One of
the sources of my confusion was the following statement:
http://www.postgresql.org/docs/8.3/interactive/app-psql.html:
\distvS
On Sun, 2009-01-11 at 17:13 -0600, Tim Hart wrote:
> Would it be worthwhile to specify this in the documentation? One of
> the sources of my confusion was the following statement:
>
> http://www.postgresql.org/docs/8.3/interactive/app-psql.html:
>
> \distvS
> "... to obtain a listing of all the
On Jan 11, 2009, at 4:41 PM, Jeff Davis wrote:
On Sun, 2009-01-11 at 15:33 -0600, Tim Hart wrote:
tjhart=# set search_path to foo, public;
SET
tjhart=# \d
List of relations
Schema | Name| Type | Owner
+---+---+
foo| bar_table | table | tjhart
On Sun, 2009-01-11 at 15:33 -0600, Tim Hart wrote:
> tjhart=# set search_path to foo, public;
> SET
> tjhart=# \d
>List of relations
> Schema | Name| Type | Owner
> +---+---+
> foo| bar_table | table | tjhart
> foo| foo_table | table | tj
Charles Seaton <[EMAIL PROTECTED]> writes:
> Thanks for your response. I am wondering whether it is postgres 8.2.5
> that resolves the problem or your time zone setting.
This behavior changed in PG 8.1. Per the release notes:
* Add a separate day field to type interval so a one day interval can
Niklas,
Thanks for your response. I am wondering whether it is postgres 8.2.5
that resolves the problem or your time zone setting.
I am running postgres 8.0.3. My server time zone is set to US/Pacific.
Setting my server time zone to one that does not have daylight saving
time causes the prob
On 3 nov 2007, at 12.26, Charles Seaton wrote:
select ('12/31/2006 UTC'::timestamptz + '307 days 02:45:30'::interval)
However, this gives an incorrect result (off by 1 hour)
"2007-11-02 18:45:30-07"
Have you checked your servers TimeZone setting? Also, which Postgres
version are you running?
"Jimmy Choi" <[EMAIL PROTECTED]> writes:
> select
>metric_type,
>case metric_type
> when 0 then
> sum (1 / val)
> when 1 then
> sum (val)
>end as result
> from metrics
> group by metric_type
The reason this does not work is that the aggregate functions are
Jimmy Choi escribió:
> This will work for this particular example. But what if my case
> statement is more complicated than that? Example:
>
> select
>metric_type,
>case metric_type
> when 0 then
> sum (1 / val)
> when 1 then
> sum (val)
> when 2 then
>
This will work for this particular example. But what if my case
statement is more complicated than that? Example:
select
metric_type,
case metric_type
when 0 then
sum (1 / val)
when 1 then
sum (val)
when 2 then
max (val)
when 3 then
On 10/3/07, Jimmy Choi <[EMAIL PROTECTED]> wrote:
> I expect to get the following result set:
>
> metric_type | result
> +---
> 0 | 2
> 1 | 3
Try:
SELECT metric_type
, SUM(CASE metric_type
WHEN 0
THEN 1 / val
On Tue, May 02, 2006 at 12:11:34PM -0500, Steve V wrote:
> >When that rule should never fire (the id hasn't changed). If I change
> >the conditional of the rule to something that must always be false
> >(like false, or 1 = 0), it will still behave in this manner.
>
> Does anyone know what's going
On 4/27/06, Strobhen <[EMAIL PROTECTED]> wrote:
Hey,
I am trying to figure out some unexpected behavior in Postgresql.
When I create a rule that fires on a table after an update, and if
that rule has a SELECT statement in it, it seems to be attempting to
fire (on an empty set) regardless of how
"James F. Hranicky" <[EMAIL PROTECTED]> writes:
> What I'd really like to do is this:
> create rule homes_update as on update to homes where OLD.fspath !=
> NEW.fspath do instead
> (
> update homes_table set record_expired = now() where fsname
> = OLD.fsn
14 matches
Mail list logo
