Hello all,
"Elephants Never Forget" sounds like a good idea. It refers to reliability
of the database (from a transaction perspective) and ability to recover
"lost data".
http://www.scientificamerican.com/article.cfm?id=elephants-never-forget
Regards,
Jayadevan
On Sun, Sep 8, 2013 at 9:20 PM, Eri
On Fri, Sep 6, 2013 at 1:58 PM, David Kerr wrote:
> I suspect this feature makes more sense on a windows platform. On linux
> where we can
> go psql -f ${SQLPATH}/file.sql . it becomes less pressing. Even Oracle
> on unix/linux where you can go sqlplus < makes
> it less a requirement.
>
I don't
On 09/08/2013 07:12 PM, jane...@web.de wrote:
Hi,
this is my query:
SELECT user,
sum(CASE WHEN lev >= 50 AND lev < 70 THEN 1 ELSE 0 END) as a,
sum(CASE WHEN lev >= 70 AND lev < 80 THEN 1 ELSE 0 END) as b,
sum(CASE WHEN lev >= 80 AND lev <= 90 THEN 1 ELSE 0 END) as c,
On 9 Září 2013, 3:12, jane...@web.de wrote:
> Hi, this is my query: SELECT user, sum(CASE WHEN lev >= 50
> AND lev < 70 THEN 1 ELSE 0 END) as a,
> sum(CASE WHEN lev >= 70 AND lev < 80 THEN 1 ELSE 0 END) as b,
> sum(CASE WHEN lev >= 80 AND lev 90 THEN 1 ELSE 0 END)
does
sum (case when lev >= 50 then 1 else 0 end) as matches
do what you want?
On Sun, Sep 8, 2013 at 9:12 PM, wrote:
> Hi,
>
> this is my query:
> SELECT user,
> sum(CASE WHEN lev >= 50 AND lev < 70 THEN 1 ELSE 0 END) as a,
> sum(CASE WHEN lev >= 70 AND lev < 80 THEN 1 E
Hi,
this is my query:
SELECT user,
sum(CASE WHEN lev >= 50 AND lev < 70 THEN 1 ELSE 0 END) as a,
sum(CASE WHEN lev >= 70 AND lev < 80 THEN 1 ELSE 0 END) as b,
sum(CASE WHEN lev >= 80 AND lev <= 90 THEN 1 ELSE 0 END) as c,
sum(CASE WHEN lev > 90 THEN 1 ELSE 0
PostgreSQL - (the worlds database)
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 09/09/13 01:27, Andreas 'ads' Scherbaum wrote:
On 09/04/2013 12:08 AM, Andreas 'ads' Scherbaum wrote:
PostgreSQL folks!
We are looking for the next big thing. Actually, it's a bit smaller: a
new design for mugs. So far we had big blue elephants, small blue
elephants, frosty elephants, white
On Sun, September 8, 2013 15:27, Andreas 'ads' Scherbaum wrote:
>
> So, we discussed a number ideas here on the lists, mainly a new text for
> the mugs. But it does not look like we have a winner.
>
> There was also this cheap shot at MySQL, but I think we all agree that
> we don't need this kind o
On 09/04/2013 12:08 AM, Andreas 'ads' Scherbaum wrote:
PostgreSQL folks!
We are looking for the next big thing. Actually, it's a bit smaller: a
new design for mugs. So far we had big blue elephants, small blue
elephants, frosty elephants, white SQL code on black mugs ... Now it's
time to design
Hello,
Create a view as described @
http://www.postgresql.org/message-id/flat/3c055b7e.bb52f...@but.auc.dk#3c055b7e.bb52f...@but.auc.dk
create view my_tbldescription as
select
u.usename, t.typname AS tblname,
a.attname, a.atttypid, n.typname AS atttypname,
int4larger(a.attlen, a.atttypmod
>I'm developing a new type, and want to have hash index on it.
>I must write a hash function for the new type, according to the PG manual,
>section 35.14.3.
>However, there is no example for this function. Actually signature of the hash
>support function
>would
12 matches
Mail list logo
