Re: temporal version of generate_series()

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "H(dot) Harada" <umi(dot)tanuki(at)gmail(dot)com>
Cc: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: temporal version of generate_series()
Date: 2008-05-01 18:36:10
Message-ID: 162867790805011136x2cf282c2n3a0530805f5b1427@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

2008/5/1 H. Harada <umi(dot)tanuki(at)gmail(dot)com>:
> 2008/5/1 H. Harada <umi(dot)tanuki(at)gmail(dot)com>:
>> 2008/5/1 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
>>
>> > Hello
>> >
>> > why you don't use polymorphic types?
>> Ah, good idea. I didn't think we could fix the third argument to
>> "interval" but "anyelement".
>> For a temporal version, it's reasonable.
>
> I was thinking about it again. There are 3 points:
>
> a. It will get complicated in the function to resolve operator for
> polymorphic types, including search for namespace and error (not
> found) handling.

yes, it's true;

> b. Other temporal data types than timestamp is easy to be casted from
> timestamp results.
> c. In the integer version of generate_series also it is possible to
> cast the results to other numerical types though harder to cast them
> to temporal data types.
>
> So it would be better to keep current patch, isn't it?
>

I missing generator for date - casting from and to timestemp is
little bit ugly - but polymorphic types in C isn't good idea, I see
it.

Regards
Pavel Stehule
>
> postgres=# select generate_series('2008/05/01 20:00'::timestamp,
> '2008/05/02 08:00'::timestamp
> , '1 hour'::interval);
> generate_series
> ---------------------
> 2008-05-01 20:00:00
> 2008-05-01 21:00:00
> 2008-05-01 22:00:00
> 2008-05-01 23:00:00
> 2008-05-02 00:00:00
> 2008-05-02 01:00:00
> 2008-05-02 02:00:00
> 2008-05-02 03:00:00
> 2008-05-02 04:00:00
> 2008-05-02 05:00:00
> 2008-05-02 06:00:00
> 2008-05-02 07:00:00
> 2008-05-02 08:00:00
> (13 rows)
>
> postgres=# select generate_series('2008/05/01 20:00'::timestamp,
> '2008/05/02 08:00'::timestamp
> , '1 hour'::interval)::time;
> generate_series
> -----------------
> 20:00:00
> 21:00:00
> 22:00:00
> 23:00:00
> 00:00:00
> 01:00:00
> 02:00:00
> 03:00:00
> 04:00:00
> 05:00:00
> 06:00:00
> 07:00:00
> 08:00:00
> (13 rows)
>
> postgres=# select generate_series('2008/05/01 20:00'::timestamp,
> '2008/05/02 08:00'::timestamp
> , '1 hour'::interval)::timestamptz;
> generate_series
> ------------------------
> 2008-05-01 20:00:00+09
> 2008-05-01 21:00:00+09
> 2008-05-01 22:00:00+09
> 2008-05-01 23:00:00+09
> 2008-05-02 00:00:00+09
> 2008-05-02 01:00:00+09
> 2008-05-02 02:00:00+09
> 2008-05-02 03:00:00+09
> 2008-05-02 04:00:00+09
> 2008-05-02 05:00:00+09
> 2008-05-02 06:00:00+09
> 2008-05-02 07:00:00+09
> 2008-05-02 08:00:00+09
> (13 rows)
>
> postgres=# select generate_series('2008/05/01 20:00'::timestamp,
> '2008/05/02 08:00'::timestamp
> , '1 hour'::interval)::date;
> generate_series
> -----------------
> 2008-05-01
> 2008-05-01
> 2008-05-01
> 2008-05-01
> 2008-05-02
> 2008-05-02
> 2008-05-02
> 2008-05-02
> 2008-05-02
> 2008-05-02
> 2008-05-02
> 2008-05-02
> 2008-05-02
> (13 rows)
>
>
> Hitoshi Harada
>
> 2008/5/1 H. Harada <umi(dot)tanuki(at)gmail(dot)com>:
>> 2008/5/1 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
>>
>> > Hello
>> >
>> > why you don't use polymorphic types?
>> Ah, good idea. I didn't think we could fix the third argument to
>> "interval" but "anyelement".
>> For a temporal version, it's reasonable.
>>
>> Also, the name "generate_time_series" is better than before?
>>
>> Hitoshi Harada
>>
>>
>> 2008/5/1 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
>>
>>
>> > Hello
>> >
>> > why you don't use polymorphic types?
>> >
>> > like:
>> >
>> > create or replace function generate_time_series(anyelement,
>> > anyelement, interval, OUT result anyelement)
>> > returns setof anyelement as $$
>> > begin
>> > result := $1;
>> > while (result <= $2) loop
>> > return next;
>> > result := result + $3;
>> > end loop;
>> > return;
>> > end;
>> > $$ language plpgsql;
>> >
>> > Regards
>> > Pavel Stehule
>> >
>> >
>> >
>> > 2008/5/1 H. Harada <umi(dot)tanuki(at)gmail(dot)com>:
>> >
>> >
>> > > Here's the sync and updated patch.
>> > > It contains "strict" in catalog as well.
>> > >
>> > > Hitoshi Harada
>> > >
>> > > 2008/4/24 H. Harada <umi(dot)tanuki(at)gmail(dot)com>:
>> > >> 2008/4/23 Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
>> > >>
>> > >> > H.Harada escribió:
>> > >> >
>> > >> >
>> > >> > > # This is my first time to send a patch. If I did something wrong, I
>> > >> > > appreciate your pointing me out.
>> > >> >
>> > >> > Brace positioning is off w.r.t. our conventions -- please fix that and
>> > >> > resubmit.
>> > >>
>> > >> Here's updated version. Thanks for your advice.
>> > >>
>> > >> Hitoshi Harada
>> > >>
>> > >> 2008/4/23 Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
>> > >>
>> > >>
>> > >> > H.Harada escribió:
>> > >> >
>> > >> >
>> > >> > > # This is my first time to send a patch. If I did something wrong, I
>> > >> > > appreciate your pointing me out.
>> > >> >
>> > >> > Brace positioning is off w.r.t. our conventions -- please fix that and
>> > >> > resubmit.
>> > >> >
>> > >> > I have added this patch to the May commitfest.
>> > >> >
>> > >> > --
>> > >> > Alvaro Herrera http://www.CommandPrompt.com/
>> > >> > The PostgreSQL Company - Command Prompt, Inc.
>> > >> >
>> > >>
>> > >
>> > >
>> > > --
>> > > Sent via pgsql-patches mailing list (pgsql-patches(at)postgresql(dot)org)
>> > > To make changes to your subscription:
>> > > http://www.postgresql.org/mailpref/pgsql-patches
>> > >
>> > >
>> >
>>
>

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2008-05-02 01:12:27 Re: Removing NONSEG mode
Previous Message KaiGai Kohei 2008-05-01 16:47:25 Re: [0/4] Proposal of SE-PostgreSQL patches