Added to TODO:
* Add temporal versions of generate_series()
http://archives.postgresql.org/pgsql-hackers/2007-04/msg01180.php
---
Jim Nasby wrote:
> On May 6, 2007, at 8:07 PM, Tom Lane wrote:
> > Jim Nasby <[EMAIL PRO
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Jim Nasby wrote:
> On May 6, 2007, at 8:07 PM, Tom Lane wrote:
> > Jim Nasby <[EMAIL PROTECTED]> writes:
> >> Also, w
On May 6, 2007, at 8:07 PM, Tom Lane wrote:
Jim Nasby <[EMAIL PROTECTED]> writes:
Also, what would be the appropriate way to put this into initdb?
You seem to have missed a step here, which is to convince people that
these belong in core at all. So far I've not even seen an argument
that
wo
Jim Nasby <[EMAIL PROTECTED]> writes:
> Also, what would be the appropriate way to put this into initdb?
You seem to have missed a step here, which is to convince people that
these belong in core at all. So far I've not even seen an argument that
would justify putting them in contrib. If they
On May 2, 2007, at 8:24 PM, JEAN-PIERRE PELLETIER wrote:
On the date variant, I wasn't sure how to handle intervals with
parts smaller than days:
floor, ceiling, round or error out
Hrm... I'm not sure what would be better there... I'm leaning towards
round (floor or ceil don't make much sen
Here's a shorter version:
On the date variant, I wasn't sure how to handle intervals with parts
smaller than days:
floor, ceiling, round or error out
To get round, the last parameters of generate_series would be
extract('epoch' FROM '1 day'::interval)::bigint * round(extract('epoch' FROM
$3) /
Here's a shorter version:
On the date variant, I wasn't sure how to handle intervals with parts
smaller than days:
floor, ceiling, round or error out
To get round, the last parameters of generate_series would be
extract('epoch' FROM '1 day'::interval)::bigint * round(extract('epoch' FROM
$3) /
On Tue, May 01, 2007 at 05:08:45PM -0400, Tom Lane wrote:
> Jim Nasby <[EMAIL PROTECTED]> writes:
> > Are you sure the case statements are needed? It seems it would be
> > better to just punt to the behavior of generate_series (esp. if
> > generate_series eventually learns how to count backward
Jim Nasby <[EMAIL PROTECTED]> writes:
> Are you sure the case statements are needed? It seems it would be
> better to just punt to the behavior of generate_series (esp. if
> generate_series eventually learns how to count backwards).
What's this "eventually"?
regression=# select * from generat
On Apr 28, 2007, at 8:00 PM, David Fetter wrote:
Here's an SQL version without much in the way of bounds checking :)
CREATE OR REPLACE FUNCTION generate_series (
start_ts timestamptz,
end_ts timestamptz,
step interval
) RETURNS SETOF timestamptz
LANGUAGE sql
AS $$
SELECT
CASE
On Thu, Apr 12, 2007 at 02:56:24PM -0700, Andrew Hammond wrote:
> I've written the following function definitions to extend
> generate_series to support some temporal types (timestamptz, date and
> time). Please include them if there's sufficient perceived need or
> value.
>
> -- timestamptz versi
On Thu, 2007-04-12 at 14:56 -0700, Andrew Hammond wrote:
> I've written the following function definitions to extend
> generate_series to support some temporal types (timestamptz, date and
> time). Please include them if there's sufficient perceived need or
> value.
I could see these being useful,
12 matches
Mail list logo
