Re: [BUGS] BUG #6456: no password
On Mon, Feb 13, 2012 at 11:50 AM, wrote: > The following bug has been logged on the website: > > Bug reference: 6456 > Logged by: tmpfs1987 > Email address: tm...@hotmail.com > PostgreSQL version: 9.0.6 > Operating system: windows xp > Description: > > I used the postgreSQL some time ago and it created an account on my windows > folder, now I re installed it after downloading a more recente version, but > now I can't finish the installation because it asks me about for a superuser > password that I don't know where to get, I tried the one from the website > registration but doesn't work. thanks for your time Just use the control panel to completely delete the postgres user, and then retry the installer. Or else change the password of the postgres user to something that you know, and then use that for the installer. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] rs.getMetaData.getTableName always return empty string
On Sun, Feb 12, 2012 at 11:42 AM, nowind_lee wrote: > I've read some discussions before I write this post. I know that > "rs.getMetaData.getTableName" always return empty string just because the > developers think it should be alias name in the query, not the underlying > table name, which is hard to implement, so it's best to leave it blank. > > And also there is a "PGResultSetMetaData.getBaseTableName()" can be used to > get the table name. > > I understand this, but it make something very hard. Please see my question: > > http://stackoverflow.com/questions/9247064/play2s-anorm-cant-work-on-postgresql > > From the implementation of play's anorm framework, we know that most of > other jdbc drivers all return the underlying table name in > "rs.getMetaData.getTableName". It make the parse of result set of "join" > query easily. > > Since all other drivers have the same action, will postgresql driver do it > too? I think return the underlying table name is much more useful than an > empty string. I think you might want to post this question to the pgsql-jdbc mailing list, rather than here. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] probleme d'installation
On Wed, Feb 15, 2012 at 6:52 PM, yannick godbout wrote: > Bonjours, > > j'ai un probleme avec l’installation de postgresql. Lorsque je viens pour > installer le programme il me demande un password et je ne connais pas le > password et je ne sais pas comment l'obtenir. je vous fait parvenir un > sprint screen que j'ai fait du programme et que j'ai mis sur le document > word que j'ai mis sur le ce e-mail. > This is an English language mailing list, but I think the solution to your problem is to go into your computer's control panel, completely remove the postgres user, and then try again. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
[BUGS] BUG #6494: Listening to * fails for IP V6
The following bug has been logged on the website: Bug reference: 6494 Logged by: Curd Reinert Email address: curd.rein...@ppi.de PostgreSQL version: 9.0.7 Operating system: AIX Description: Hello everyone, on a AIX with IP V6 enabled, I try to listen on all interfaces listen_addresses = '*' and get LOG: could not bind IPv6 socket: Der Socket-Name wird bereits verwendet. HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry. Of course I made sure there was nothing running on that port. I can then connect to the database using 127.0.0.1, but not with ::1. If instead I specify the IP addresses explictly, listen_addresses = '127.0.0.1,fdeb:df42:ebda:0815:0:0:0:18,::1' then there is no error and I can connect to all the addresses. 'localhost' instead of '*' also works, but I want to connect remotely. It's a 9.0.7 which was build on AIX 5.3 with readline, zlib and thread-safety disabled. The machine I originally tried to run it is a AIX 6.1. Symptoms on the 5.3 are the same. We only have this trouble on AIX. We are already connection succesfully remotely over IP V6 to database running on Linux, Solaris, and Windows 7 (as far as I know). I didn't find anything useful in FAQ or TODO, I hope I didn't miss something obvious. Many thanks, Curd -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6490: Not checking column existence in sub query
On Mon, Feb 27, 2012 at 11:39:55AM +, anisim...@gmail.com wrote: > The following bug has been logged on the website: > > Bug reference: 6490 > Logged by: Timofey Anisimov > Email address: anisim...@gmail.com > PostgreSQL version: 9.1.2 > Operating system: Linux > Description: > > SELECT * FROM table1 where col1 in (select col2 from table2) > > if col2 exist in table1 and not exist in table2 there will be no error and > query output all rows from table1; sure. it is so called "correlated subquery" and it's definitely not a bug. Best regards, depesz -- The best thing about modern society is how easy it is to avoid contact with it. http://depesz.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6490: Not checking column existence in sub query
The following bug has been logged on the website: Bug reference: 6490 Logged by: Timofey Anisimov Email address: anisim...@gmail.com PostgreSQL version: 9.1.2 Operating system: Linux Description: SELECT * FROM table1 where col1 in (select col2 from table2) if col2 exist in table1 and not exist in table2 there will be no error and query output all rows from table1; -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
