The current version of psql, pg_dump, ... do not properly prompt the
user for a password, when the backend database is setup for password
authentication on a Windows platform. In investigating the code, I
noticed that the file '/dev/tty' is opened to interact with the console.
It appears as if on
Robert Kinberg [EMAIL PROTECTED] writes:
The current version of psql, pg_dump, ... do not properly prompt the
user for a password, when the backend database is setup for password
authentication on a Windows platform.
Curious that you are the *only* person to have noticed such a
fundamental
Neil Conway wrote:
Context diffs are preferred. Also, diffs should be against the root of
the source tree, and attached as MIME attachements if possible (it seems
the mailing list software munges the patch somewhat otherwise).
Minor nit: lowercase Append. Similarly, consistent capitalization
Tom,
There are several posts to the internet about this issue. I found no
solution to these posts either.
Here is a except from a post on the pgsql-bugs mailing list:
Hello,
I have a problem with psql on Windows XP Pro. After an attempt to
connect to a database I get this error:
psql:
I was very surprised by this issue as well. I am just
assuming that not many people have a c:\dev directory on
their machines where they run postgreSQL from. That is the
only way that you would be able to open the file '/dev/tty',
if the cwd is c:.
If I switch my cwd to a drive that
P. Scott DeVos wrote:
I'm on it.
Actually, don't worry about it -- I've made the corrections I had in
mind myself. Attached is a revised patch. On looking closer, I didn't
really like the way the patch accumulated the lines of the traceback:
AFAICS _PyString_Join() is not an official Python
Neil Conway wrote:
Actually, don't worry about it -- I've made the corrections I had in
mind myself. Attached is a revised patch. On looking closer, I didn't
really like the way the patch accumulated the lines of the traceback:
AFAICS _PyString_Join() is not an official Python C API
P. Scott DeVos wrote:
Are you sure this works: PyString_AsString(lno)? lno is a python
integer object. Maybe we want, PyString_AsString(PyObject_Str(lno))
Wait, this is not the way to do it because PyObject_Str returns a new
reference. I think you have to assign PyObject_Str(lno)
Outstanding writeup! Mind if I post it in our knowledgebase at
http://www.pervasivepostgres.com/instantkb13/? (Unless someone has a
better idea of where this could go...)
On Sun, Feb 12, 2006 at 04:33:27PM -0500, Chris Campbell wrote:
The definitive answer can be found in the source code for the
On Fri, Jan 06, 2006 at 04:46:26PM +1300, Mark Kirkwood wrote:
Jim C. Nasby wrote:
On Fri, Jan 06, 2006 at 02:00:34PM +1300, Mark Kirkwood wrote:
However, I think the actual change is not quite right - after running
DOH! It would be good if doc/src had a better mechanism for handling
On Sun, Feb 19, 2006 at 09:40:46PM -0500, Tom Lane wrote:
tape. This increases the space needed by 8 or 12 bytes (depending on
sizeof(Datum)) per in-memory tuple, but doesn't cost anything as far as
Stupid question... how are varlena's handled in Datum?
--
Jim C. Nasby, Sr. Engineering
Jim C. Nasby [EMAIL PROTECTED] writes:
Stupid question... how are varlena's handled in Datum?
The Datum is just a pointer into the original tuple in that case.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you
12 matches
Mail list logo
