On 08/22/2012 08:36 AM, Denis Kolesnik wrote:
I have now VERY strong argument to consider it is as a bug:
if there a understandable for SQL language sequence which sorts
in other fashion when adding "LIMIT".
Underspecified sorts can have unstable results, that's allowed by the
spec and is a r
On 08/23/2012 04:12 AM, Denis Kolesnik wrote:
Suppose a person who has basic SQL knowledges would learn on praxis
how would result a query if a person adds the clause "limit 1" to it
Then they just got bitten by not learning enough and not testing their
code well enough; they were probably pr
Robert Haas writes:
> On Tue, Aug 21, 2012 at 4:30 PM, Tom Lane wrote:
>> Meanwhile, back at the ranch: I'm fine with applying that patch now that
>> it's had some field testing.
> Attached is a version that applies OK to 9.1, after resolving some
> conflicts. Review appreciated. It wasn't exa
Denis Kolesnik writes:
> You would sugguest, that one should read documentation.
Indeed.
> in the (where with ... replaced a directory in which the PostgreSQL installed)
> ...PostgreSQL\9.1\doc\postgresql\html\queries-limit.html
> "...When using LIMIT, it is important to use an ORDER BY clause
My arguments are:
is that even
select id, str_last_name from tbl_owners_individual where id in
(83,175,111,1) order by id;
id |str_last_name
-+--
1 | Kolesnik
83 | GX
111 | Kolesnik
175 | GX
(4 строки)
select id, str_last_name from tbl_owners
Chris Travers writes:
> On Wed, Aug 22, 2012 at 8:04 AM, Tom Lane wrote:
>> Chris Travers writes:
> mtech_test=# explain analyze select (account_heading__list()).* group by accno
>> Hm, that really ought to throw an error, since you have ungrouped
>> columns in the result. Not sure why it does
Denis Kolesnik wrote:
> My arguments are:
>
> is that even
> select id, str_last_name from tbl_owners_individual where id in
> (83,175,111,1) order by id;
>
> id |str_last_name
> -+--
>1 | Kolesnik
> 83 | GX
> 111 | Kolesnik
> 175 | GX
> (
"Kevin Grittner" wrote:
> Denis Kolesnik wrote:
>> and even sorting by id:
>> select id, str_last_name from tbl_owners_individual where id in
>> (83,175,111,1) order by str_last_name;
>>
>> id |str_last_name
>> -+--
>> 83 | GX
>> 175 | GX
>>
Denis Kolesnik wrote:
> I have now VERY strong argument to consider it is as a bug:
No, you appear to have very strong feelings about it, but you are
not making an argument that holds water.
> if there a understandable for SQL language sequence which sorts
> in other fashion when adding "LIM
On Wed, Aug 22, 2012 at 8:04 AM, Tom Lane wrote:
> Chris Travers writes:
>> It's when we add group by that things appear broken. Note it starts
>> returning 196 (14 x 14) records, which suggests a cross join against
>> itself.
>
>> mtech_test=# explain analyze select (account_heading__list()).*
Chris Travers writes:
> It's when we add group by that things appear broken. Note it starts
> returning 196 (14 x 14) records, which suggests a cross join against
> itself.
> mtech_test=# explain analyze select (account_heading__list()).* group by accno
> mtech_test-# ;
Hm, that really ought to
Hi all;
In some of my tests regarding set-returning functions I came across
some very strange behavior. Group by seems to have very strange (and
inconsistent) behavior when connected to the use of a set-returning
function in a column list.
Consider the following function which returns a list of
I have now VERY strong argument to consider it is as a bug:
if there a understandable for SQL language sequence which sorts
in other fashion when adding "LIMIT".
I did try the same with a last name starting with "G" (there also more
than one entry with identical surnames) and it worked ok(the res
On Wednesday, August 22, 2012 12:08:25 PM Maxim Boguk wrote:
> > > Does that mean that file was damaged during rsync?
> >
> > Not necessarily. When did you initially set up that cluster? Normally the
> > file
> > should get zeroed out before its being used. If the cluster was copied
> > improperly
> > Does that mean that file was damaged during rsync?
> Not necessarily. When did you initially set up that cluster? Normally the
> file
> should get zeroed out before its being used. If the cluster was copied
> improperly (i.e. no pg_start/stop backup or such) it could easily happen.
> But
> I wo
On Thu, Aug 2, 2012 at 6:34 AM, raf wrote:
> Tom Lane wrote:
>
> > raf writes:
> > > i've just upgraded to 9.1.4 on macosx-10.6.8 and psql crashes
> > > whenever the -h option is used (either with "localhost" or any
> > > other hostname). i only have hostssl connections.
> >
> > > attached is a
Hi Maxim,
On Wednesday, August 22, 2012 06:18:14 AM Maxim Boguk wrote:
> On Wed, Aug 22, 2012 at 1:50 PM, Maxim Boguk wrote:
> > On Wed, Aug 22, 2012 at 6:08 AM, Andres Freund
wrote:
> >> On Tuesday, August 21, 2012 03:30:44 PM Maxim Boguk wrote:
> >> > Hi Andres,
> >>
> >> I would add somethin
17 matches
Mail list logo
