On 11/03/16 08:48, Igal @ Lucee.org wrote:
On 3/10/2016 11:44 AM, Robert Haas wrote:
On Thu, Mar 10, 2016 at 2:35 PM, Simon Riggs
wrote:
But I still don't know "meh" means.
Maybe this helps?
https://en.wikipedia.org/wiki/Meh
LOL
https://en.wikipedia.org/wiki/LOL
I'm pretending to work,
On Thu, Mar 10, 2016 at 11:45 AM, Robert Haas wrote:
> On Thu, Mar 10, 2016 at 11:33 AM, David G. Johnston
> wrote:
> > I tend to think we err toward this too much. This seems like development
> > concerns trumping usability. Consider that anything someone took the
> time
> > to write and poli
On 3/10/2016 11:44 AM, Robert Haas wrote:
On Thu, Mar 10, 2016 at 2:35 PM, Simon Riggs wrote:
But I still don't know "meh" means.
Maybe this helps?
https://en.wikipedia.org/wiki/Meh
LOL
https://en.wikipedia.org/wiki/LOL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Thu, Mar 10, 2016 at 2:35 PM, Simon Riggs wrote:
> But I still don't know "meh" means.
Maybe this helps?
https://en.wikipedia.org/wiki/Meh
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
On 10 March 2016 at 18:45, Robert Haas wrote:
> On Thu, Mar 10, 2016 at 11:33 AM, David G. Johnston
> wrote:
> > I tend to think we err toward this too much. This seems like development
> > concerns trumping usability. Consider that anything someone took the
> time
> > to write and polish to m
On Thu, Mar 10, 2016 at 11:33 AM, David G. Johnston
wrote:
> I tend to think we err toward this too much. This seems like development
> concerns trumping usability. Consider that anything someone took the time
> to write and polish to make committable to core was obviously genuinely
> useful to
removed leftover development comment
On Thu, Mar 10, 2016 at 11:02 AM, Corey Huinker
wrote:
> On Thu, Mar 10, 2016 at 10:58 AM, Robert Haas
> wrote:
>
>> On Thu, Mar 10, 2016 at 10:30 AM, Simon Riggs
>> wrote:
>> > On 10 March 2016 at 06:53, Michael Paquier
>> > wrote:
>> >>
>> >> On Wed, Mar
On Thu, Mar 10, 2016 at 9:30 AM, Michael Paquier
wrote:
> On Thu, Mar 10, 2016 at 4:58 PM, Robert Haas
> wrote:
> > On Thu, Mar 10, 2016 at 10:30 AM, Simon Riggs
> wrote:
> >> On 10 March 2016 at 06:53, Michael Paquier
> >> wrote:
> >>>
> >>> On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera
> >
On Thu, Mar 10, 2016 at 8:58 AM, Robert Haas wrote:
> On Thu, Mar 10, 2016 at 10:30 AM, Simon Riggs
> wrote:
> > On 10 March 2016 at 06:53, Michael Paquier
> > wrote:
> >>
> >> On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera
> >> wrote:
> >> > Robert Haas wrote:
> >> >> I'm pretty meh about th
On Thu, Mar 10, 2016 at 4:58 PM, Robert Haas wrote:
> On Thu, Mar 10, 2016 at 10:30 AM, Simon Riggs wrote:
>> On 10 March 2016 at 06:53, Michael Paquier
>> wrote:
>>>
>>> On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera
>>> wrote:
>>> > Robert Haas wrote:
>>> >> I'm pretty meh about the whole id
Corey Huinker wrote:
> New patch for Alvaro's consideration.
Thanks. As I said, it will be a few days before I get to this; any
further reviews in the meantime are welcome.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training &
On Thu, Mar 10, 2016 at 10:58 AM, Robert Haas wrote:
> On Thu, Mar 10, 2016 at 10:30 AM, Simon Riggs
> wrote:
> > On 10 March 2016 at 06:53, Michael Paquier
> > wrote:
> >>
> >> On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera
> >> wrote:
> >> > Robert Haas wrote:
> >> >> I'm pretty meh about t
On Thu, Mar 10, 2016 at 10:30 AM, Simon Riggs wrote:
> On 10 March 2016 at 06:53, Michael Paquier
> wrote:
>>
>> On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera
>> wrote:
>> > Robert Haas wrote:
>> >> I'm pretty meh about the whole idea of this function, though,
>> >> actually, and I don't see a
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Simon Riggs wrote:
> > On 10 March 2016 at 06:53, Michael Paquier
> > wrote:
> >
> > > On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera
> > > wrote:
> > > > Robert Haas wrote:
> > > >> I'm pretty meh about the whole idea of this function, thoug
Simon Riggs wrote:
> On 10 March 2016 at 06:53, Michael Paquier
> wrote:
>
> > On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera
> > wrote:
> > > Robert Haas wrote:
> > >> I'm pretty meh about the whole idea of this function, though,
> > >> actually, and I don't see a single clear +1 vote for this
On 10 March 2016 at 06:53, Michael Paquier
wrote:
> On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera
> wrote:
> > Robert Haas wrote:
> >> I'm pretty meh about the whole idea of this function, though,
> >> actually, and I don't see a single clear +1 vote for this
> >> functionality upthread. (Apo
Robert Haas wrote:
> That's probably marginally enough support to proceed with this, but
> I'm somewhat unenthused about putting time into it myself. Alvaro,
> any chance you want to handle this one?
OK, I can take it, but I have a few other things earlier in my queue so
it will be a few days.
On Thu, Mar 10, 2016 at 1:53 AM, Michael Paquier
wrote:
> On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera
> wrote:
>> Robert Haas wrote:
>>> I'm pretty meh about the whole idea of this function, though,
>>> actually, and I don't see a single clear +1 vote for this
>>> functionality upthread. (Ap
On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> I'm pretty meh about the whole idea of this function, though,
>> actually, and I don't see a single clear +1 vote for this
>> functionality upthread. (Apologies if I've missed one.) In the
>> absence of a few of those
Robert Haas wrote:
> Let's yank 'em. This is a minor issue which is distracting us from
> the main point of this patch, and I don't think it's worth getting
> distracted.
+1
> I'm pretty meh about the whole idea of this function, though,
> actually, and I don't see a single clear +1 vote for th
On Tue, Mar 8, 2016 at 3:57 PM, Corey Huinker
wrote:
>
>> I'm pretty meh about the whole idea of this function, though,
>> actually, and I don't see a single clear +1 vote for this
>> functionality upthread. (Apologies if I've missed one.) In the
>> absence of a few of those, I recommend we rej
>
> > It would be simple enough to remove the infinity test on the "stop" and
> > leave it on the "start". Or yank both. Just waiting for others to agree
> > which checks should remain.
>
> Let's yank 'em. This is a minor issue which is distracting us from
> the main point of this patch, and I don
On Fri, Mar 4, 2016 at 3:17 PM, Corey Huinker wrote:
>>
>> I feel rather uneasy about simply removing the 'infinity' checks. Is there
>> a way to differentiate those two cases, i.e. when the generate_series is
>> called in target list and in the FROM part? If yes, we could do the check
>> only in
>
>
> I feel rather uneasy about simply removing the 'infinity' checks. Is there
> a way to differentiate those two cases, i.e. when the generate_series is
> called in target list and in the FROM part? If yes, we could do the check
> only in the FROM part, which is the case that does not work (and
Hi,
On 02/22/2016 08:04 PM, Corey Huinker wrote:
>
> Given that counterexample, I think we not only shouldn't back-patch such a
> change but should reject it altogether.
Ouch, good point. The overflows are a different problem that we had
better address though (still on my ow
>
> >
> > Given that counterexample, I think we not only shouldn't back-patch such
> a
> > change but should reject it altogether.
>
> Ouch, good point. The overflows are a different problem that we had
> better address though (still on my own TODO list)...
>
So I should remove the bounds checking
On Mon, Feb 22, 2016 at 6:52 AM, Tom Lane wrote:
> Oooh ... actually, that works today if you consider the SRF-in-targetlist
> case:
>
> regression=# select generate_series(now(), 'infinity', '1 day') limit 10;
> generate_series
> ---
> 2016-02-21 16:51:03.3030
Christoph Berg writes:
> Re: David Fetter 2016-01-26 <20160126180011.ga16...@fetter.org>
>> +1 for back-patching. There's literally no case where an infinite
>> input could be correct as the start or end of an interval for
>> generate_series.
> select * from generate_series(now(), 'infinity', '1
Re: David Fetter 2016-01-26 <20160126180011.ga16...@fetter.org>
> +1 for back-patching. There's literally no case where an infinite
> input could be correct as the start or end of an interval for
> generate_series.
select * from generate_series(now(), 'infinity', '1 day') limit 10;
... seems pre
On 26.01.2016 13:53, Michael Paquier wrote:
Imagine for example a script that in some rare cases passes happens to
pass infinity into generate_series() - in that case I'd much rather error
out than wait till the end of the universe.
So +1 from me to checking for infinity.
+1
ERROR infinite
Simon Riggs wrote:
> On 25 January 2016 at 09:55, Tomas Vondra
> wrote:
>
>
> > Imagine for example a script that in some rare cases passes happens to
> > pass infinity into generate_series() - in that case I'd much rather error
> > out than wait till the end of the universe.
> >
> > So +1 from
Revised patch:
Differences in this patch vs my first one:
- infinite bounds generate errors identical to Michael's timestamp patch
(though I did like Simon's highly optimistic error message).
- Bounds checking moved before memory context allocation
- arg variable "finish" renamed "stop" to match p
On 26-01-2016 09:53, Michael Paquier wrote:
> Something like the patch attached would be fine? This wins a backpatch
> because the query continuously running eats memory, no?
>
+1. Although it breaks compatibility, a function that just eats
resources is not correct.
--
Euler Taveira
On Tue, Jan 26, 2016 at 09:53:26PM +0900, Michael Paquier wrote:
> On Tue, Jan 26, 2016 at 7:00 PM, Torsten Zuehlsdorff
> wrote:
> >
> > On 26.01.2016 07:52, Simon Riggs wrote:
> >
> >>> Imagine for example a script that in some rare cases passes
> >>> happens to pass infinity into generate_series
On Tue, Jan 26, 2016 at 7:53 AM, Michael Paquier
wrote:
> On Tue, Jan 26, 2016 at 7:00 PM, Torsten Zuehlsdorff
> wrote:
> >
> > On 26.01.2016 07:52, Simon Riggs wrote:
> >
> >>> Imagine for example a script that in some rare cases passes happens to
> >>> pass infinity into generate_series() - in
On Tue, Jan 26, 2016 at 7:00 PM, Torsten Zuehlsdorff
wrote:
>
> On 26.01.2016 07:52, Simon Riggs wrote:
>
>>> Imagine for example a script that in some rare cases passes happens to
>>> pass infinity into generate_series() - in that case I'd much rather error
>>> out than wait till the end of the u
On 26.01.2016 07:52, Simon Riggs wrote:
Imagine for example a script that in some rare cases passes happens to
pass infinity into generate_series() - in that case I'd much rather error
out than wait till the end of the universe.
So +1 from me to checking for infinity.
+1
ERROR infinite res
On 25 January 2016 at 09:55, Tomas Vondra
wrote:
> Imagine for example a script that in some rare cases passes happens to
> pass infinity into generate_series() - in that case I'd much rather error
> out than wait till the end of the universe.
>
> So +1 from me to checking for infinity.
>
+1
E
On Mon, Jan 25, 2016 at 6:55 PM, Tomas Vondra
wrote:
> On 01/25/2016 07:22 AM, Tom Lane wrote:
>>
>> Michael Paquier writes:
>>>
>>> On Mon, Jan 25, 2016 at 3:00 PM, Corey Huinker
>>> wrote:
One thing I discovered in doing this patch is that if you do a timestamp
generate_series i
On Mon, Jan 25, 2016 at 2:07 AM, Tom Lane wrote:
> Corey Huinker writes:
> > Incidentally, is there a reason behind the tendency of internal functions
> > to avoid parameter defaults in favor of multiple pg_proc entries?
>
> Yes: you can't specify defaults in pg_proc.h.
>
> We work around that w
On 01/25/2016 07:22 AM, Tom Lane wrote:
Michael Paquier writes:
On Mon, Jan 25, 2016 at 3:00 PM, Corey Huinker wrote:
One thing I discovered in doing this patch is that if you do a timestamp
generate_series involving infinityit tries to do it. I didn't wait to
see if it finished.
Well,
Corey Huinker writes:
> Incidentally, is there a reason behind the tendency of internal functions
> to avoid parameter defaults in favor of multiple pg_proc entries?
Yes: you can't specify defaults in pg_proc.h.
We work around that where absolutely necessary, see the last part of
system_views.sq
>
>
> If it didn't respond to SIGINT, that would be an issue, but otherwise
> this doesn't seem much more exciting than any other way to create a
> query that will run longer than you want to wait.
>
> regards, tom lane
>
It responded to SIGINT, so yeah, meh.
I can see val
Michael Paquier writes:
> On Mon, Jan 25, 2016 at 3:00 PM, Corey Huinker
> wrote:
>> One thing I discovered in doing this patch is that if you do a timestamp
>> generate_series involving infinityit tries to do it. I didn't wait to
>> see if it finished.
> Well, I would think that this is a
On Mon, Jan 25, 2016 at 3:00 PM, Corey Huinker wrote:
> This patch addresses a personal need: nearly every time I use
> generate_series for timestamps, I end up casting the result into date or the
> ISO string thereof. Like such:
>
> [...]
>
> One thing I discovered in doing this patch is that if
This patch addresses a personal need: nearly every time I use
generate_series for timestamps, I end up casting the result into date or
the ISO string thereof. Like such:
SELECT d.dt::date as dt
FROM generate_series('2015-01-01'::date,
'2016-01-04'::date,
i
46 matches
Mail list logo
