Re: [SQL] casting character varying to integer - order by numeric
Tom Lane wrote: But postgres 7 rejects this with "ERROR: cannot cast type character varying to integer". As a general rule, you need to be more specific than that about which version you are working with ;-) You may find that username::text::integer will work, depending on which 7.x this actually is. regards, tom lane Oooh, I'd be so happy to. But I don't know. Yes, I don't know. I know which version of "psql" is installed on my local machine, but the actual database is remote. Is there a command to get the server version? As close as I can find is: stage=> \copyright PostgreSQL Data Base Management System Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group -Bryce PS: If it's a hint, "select username from eg_member order by username::text::integer" works fine. Thanks.
Re: [SQL] casting character varying to integer - order by numeric
Bryce Nesbitt (mailing list account) wrote: Tom Lane wrote: As a general rule, you need to be more specific than that about which version you are working with ;-) Oooh, I'd be so happy to. But I don't know. Yes, I don't know. I know which version of "psql" is installed on my local machine, but the actual database is remote. Is there a command to get the server version? As close as I can find is: stage=> \copyright SELECT version(); -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[SQL] Sql - Error : Relation tmp_datos already exists
Hello!
Mario Splivalo:Thank you very much for your helpl!!!
I´m working with postgres 7.4.1. and VFoxPro 5. I call a function (Postgresql) many times from VFoxPro:
sql = "select * from f_rep_datos_lab( 'USUARIO')"aaa=sqlexec(db_cone,sql, "report")
This function use temporary tables wich are created with "ON COMMIT DROP".
There is a problem because the temporary table already exists during the second execution of the function. ("Relation tmp_datos already exists")
But...iIf i call this function many times in the same PgAdmin' session, f.e., there weren't problems. The querys in that functions are execuded with "EXECUTE".
Whi?what's wrong whit this calling?
Any idea will be welcome.
Thanks
Adriana
1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
Abrí tu cuenta aquí
[SQL] Problema con migracion de SQL a PostgreSQL
Subject: Migracion de SQL Server 2000 a PostgreSQL hola a todos, tengo un problema hace unos dias y necesito resolverlo cuanto antes. Necesito migrar la Base de Datos de un Portal Corporativo que desarrolle en SQL a Postgresql, pero no encuentro manera de hacerlo, trate de hacerlo por el export de SQL SErver 2000 pero no me exporta los SP, y para colmo tengo mas de 40 Procedimientos Almacenados (SP) que no quisiera reimplementar ademas que no tendria sentido. Yo se que Postgresql no tiene procedimientos almacenados de forma literal pero si tiene funciones o algo para encapsular consultas y devolver atributos. Necesito que si alguien ha resuelto esto me diga que hizo pues me urge saber. Gracias a todos. Me pueden responder por aqui [EMAIL PROTECTED]
Re: [SQL] casting character varying to integer - order by numeric
Cool, thanks. PostgreSQL 7.4.2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-20) Richard Huxton wrote: SELECT version(); ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [SQL] pg, mysql comparison with "group by" clause
Greg Stark wrote: "Anthony Molinaro" <[EMAIL PROTECTED]> writes: Greg, You'll have to pardon me... I saw this comment: "I don't see why you think people stumble on this by accident. I think it's actually an extremely common need." Which, if referring to the ability to have items in the select that do not need to be included in the group, (excluding constants and the like) is just silly. Well the "constants and the like" are precisely the point. There are plenty of cases where adding the column to the GROUP BY is unnecessary and since Postgres makes no attempt to prune them out, inefficient. And constants aren't the only such case. The most common case is columns that are coming from a table where the primary key is already included in the GROUP BY list. I sort of see what you are saying but you have yet to convince me In the case of columns coming from a table where the primary key is already in the GROUP BY list it's possible for the database to deduce that it's unnecessary to group on that column. Well The question is really whether two things should be true: 1) whether you want to assume that the programmer is going to know about Single/Multi Value Dependency issues per column. IMO, this is more of a DB design issue than a client app issue. And I would *not* want to make that assumption because for higher normal forms where this is likely to be a consideration, you are likely to have denormalized access via VIEWs anyway. 2) Whether you are willing to rely on looking at the data first to determine whether the query is valid Alternatively we are back to the ability to get the wrong answer with ease and in very difficult to debug ways. I suspect that MySQL places an implicit MIN() around columns not included in the group by statement. I fail to see why this is not an appropriate answer to his concern. But it's also possible to have cases where the programmer has out of band knowledge that it's unnecessary but the database doesn't have that knowledge. The most obvious case that comes to mind is a denormalized data model that includes a redundant column. select dept_id, dept_name, count(*) from employee_list Ok. You have a few choices: SELECT MIN(dept_id), dept_name, count(*) FROM employee_list GROUP BY dept_name; SELECT dept_id, dept_name, count(*) FROM employee_list GROUP BY dept_name, dept_id; SELECT dept_id, MIN(dept_name), count(*) FROM employee_list GROUP BY dept_id; And yes, it is bad design in every case I can think of.// Why is this a problem? Best Wishes, Chris Travers Metatron Technology Consulting ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
