Re: [GENERAL] Daylight Savings Time handling on persistent connections
On Sun, Oct 31, 2004 at 05:55:23PM -0500, Tom Lane wrote: [...] I'm inclined to think that rejecting impossible or ambiguous input without a zone is reasonable (and it would go along with the changes we made in 7.4 to tighten up datetime field order assumptions). But I don't want to take away the convenience of leaving off the zone altogether. One point here is that timestamp-to-timestamptz datatype conversion will be affected by whatever we choose. While it's easy to say reject it for data coming into a database, it's less easy to say that a coercion function should fail on some inputs it didn't use to fail on. What about letting the user decide on the behaviour through a config option? I really missed this when the integer parsing changed. The default could be to reject ambiguous input, allowing the user to choose the assumed zone if he wants to, in a global and per-connection basis. -- Vinko Vrsalovic el[|[EMAIL PROTECTED]|]vinko.cl ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Daylight Savings Time handling on persistent connections
On Mon, Nov 01, 2004 at 07:08:39PM +0100, Martijn van Oosterhout wrote: For the parsing integer issue it may have worked, but this is another kettle of fish. I don't think you can do this as a simple switch, it would have to set during the initdb and not allowed to be changed afterwards. I don't know if that something that can be supported. I suspected it wasn't that easy. Anyhow, I strongly believe that when no reasonable defaults can be deduced, the software should give the user the ability to decide what he wants to do. Of course technical (implementation, maintenance, etc.) issues are highly relevant and if it can't reasonably be done, well, tough luck, but I think (and I don't have a clue about the internals of PostgreSQL, so take this with two grains of salt) a solution such as the one you mention should be given consideration. -- Vinko Vrsalovic el[|[EMAIL PROTECTED]|]vinko.cl ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Superuser log-in through a web interface?
On Sun, Oct 31, 2004 at 05:24:34AM -0500, Ken Tozier wrote: On Oct 31, 2004, at 1:29 AM, Kevin Barnard wrote: You have a conceptual error. When connecting you are connecting to a database. With out the database you are not connecting to anything hence the failure. That explains it, thanks. Another pesky problem I've run into is that I can enter literally anything into the user name and password fields of my php form and it still logs in. What's up with that? Is there some way find out the user for a given connection? This is probably because pg_hba.conf settings. By default, it trusts connections from localhost, which means that any connection being made from localhost (which is the case when the web server and database are running in the same machine) will be accepted regardless of user and password. You should change these lines in pg_hba.conf local all all trust # IPv4-style local connections: hostall all 127.0.0.1/32 trust and change 'trust' to your preferred auth method (password, md5, etc.) Check out the docs for authentication methods at http://www.postgresql.org/docs/7.4/interactive/client-authentication.html HTH, -- Vinko Vrsalovic el[|[EMAIL PROTECTED]|]vinko.cl ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] 8.0 Beta 4 denying network connections?
On Fri, Oct 29, 2004 at 09:59:17PM -0400, Tom Lane wrote: Vinko Vrsalovic [EMAIL PROTECTED] writes: [EMAIL PROTECTED] sources 20:55:07]$ telnet mymachine 5431 Trying 192.168.0.169... telnet: Unable to connect to remote host: Connection refused Looks to me like you forgot to enable TCP connections in the 8.0 installation. Note that the relevant postgresql.conf options are not the same in 8.0 as 7.4 (see listen_addresses vs tcpip_socket and virtual_host). Shame on me, I checked the file 6 times and every time read defaults to '*' = any. Thanks a lot, -- Vinko Vrsalovic el[|[EMAIL PROTECTED]|]vinko.cl ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[GENERAL] 8.0 Beta 4 denying network connections?
Hello, I've got one 7.4 installation and a brand new 8.0 beta4 running on the same machine. Both installations are configured to use the same port (5431) to avoid reconfiguring the apps running on top of the DB. The following paragraphs illustrate the problem: [EMAIL PROTECTED] root 20:52:07]# service postgres74 start Starting PostgreSQL: ok [EMAIL PROTECTED] sources 20:54:36]$ telnet mymachine 5431 Trying 192.168.2.69... Connected to mymachine.mydomain.cl (192.168.0.169). Escape character is '^]'. null Connection closed by foreign host. [EMAIL PROTECTED] root 20:55:50]# service postgres74 stop Stopping PostgreSQL: ok [EMAIL PROTECTED] root 20:55:56]# service postgres8 start Starting PostgreSQL: ok [EMAIL PROTECTED] sources 20:55:07]$ telnet mymachine 5431 Trying 192.168.0.169... telnet: Unable to connect to remote host: Connection refused If I try connecting from localhost, I can connect without trouble in both versions. And, of course, the same happens with the psql client. I tried modifying pg_hba.conf but to no avail and what I have looks right to me. Has the syntax for this file changed? I even tried to use the 74's pg_hba with 80, but the results are the same. Is there another config option I'm missing? FWIW, beta3 doesn't behave this way. Thanks for any insight on the issue, -- Vinko Vrsalovic el[|[EMAIL PROTECTED]|]vinko.cl ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
