- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
Sent: January 02, 2003 1:34 AM
> Perhaps it would work better to do something like
>
> #ifdef HAVE_GETOPT_LONG
> char* f_option = _("-f, --file=FILENAME ");
> ... etc ...
> #else /* not HAVE_GETOPT_LONG */
> char* f_option = _
Hmmm...I wonder if this will mean we'll be accused of "ballot stuffing" in
the MySQL lists again...
It is a newbie forum, so I'm not surprised that MySQL is way ahead.
The poll is a bit of a joke anyway.
The poll needs to have two questions:
1. Which of these databases have you ACTUALLY USED?
"Serguei Mokhov" <[EMAIL PROTECTED]> writes:
> Attached is an attempt to eliminate duplicate pg_dump
> option descriptions, and have a single description for both
> short and long options. For me, as for a translator, this
> eliminates the need to maintain the two, exactly same, sets of
> 24 sente
Just got this in my mailbox:
2002 LinuxQuestions.org Members Choice Awards:
http://www.linuxquestions.org/questions/showthread.php?s=78a8c06fbc1dcecd52597decd6c56ad8&threadid=39870
And we are way behind MySQL (like, d'ah!):
http://www.linuxquestions.org/questions/poll.php?s=78a8c06fbc1dcecd525
Hello,
Happy New Year everyone,
Attached is an attempt to eliminate duplicate pg_dump
option descriptions, and have a single description for both
short and long options. For me, as for a translator, this
eliminates the need to maintain the two, exactly same, sets of
24 sentences.
If this is acc
Yes, I have been feeling we should do that. Justin pointed out just
yesterday that .pgpass is only mentioned in libpq documentation, and in
fact there is lots of stuff mentioned in libpq that releates to the
other interfaces, so it should be pulled out and put in one place.
Does anyone want to t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What do others think? I am not sure myself.
There should definitely be someplace that recommends using SSL across
insecure networks (if there's not already). But it doesn't seem to me
to qualify as a FAQ entry. Somewhere in the admin guide seems more
What do others think? I am not sure myself.
---
mlw wrote:
>
>
> Bruce Momjian wrote:
>
> >mlw wrote:
> >
> >
> >>>The comments at the top suggest sniffing a Postgres session startup
> >>>exchange in order to see the M
Bruce Momjian wrote:
mlw wrote:
The comments at the top suggest sniffing a Postgres session startup
exchange in order to see the MD5 value that the user presents; which the
attacker would then give to this program. (Forget it if the session is
Unix-local rather than TCP,
mlw wrote:
> >The comments at the top suggest sniffing a Postgres session startup
> >exchange in order to see the MD5 value that the user presents; which the
> >attacker would then give to this program. (Forget it if the session is
> >Unix-local rather than TCP, or if it's SSL-encrypted...)
> >
>
The error message says all. You are trying to insert a character which
is not a UTF-8. Probably you are inputting UCS-2?
--
Tatsuo Ishii
From: "Atahualpa Jones" <[EMAIL PROTECTED]>
Subject: Postgresql, unicode and umlauts
Date: Wed, 1 Jan 2003 20:17:15 +0100
Message-ID: <000d01c2b1ca$67838d60$150
Tom Lane wrote:
Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
I had no time to search throug the code; but as far as I understood, it
*attacks* the database servers with TCP/IP on, right?
No, the program itself simply takes an MD5 hash value and does a
brute-force search f
On Wed, 1 Jan 2003, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > I see the values being stored on constriant creation, but not being used
> > > anywhere:
> >
> > I believe the values that actually get inspected at runtime are the
> > tgdeferrable and
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I see the values being stored on constriant creation, but not being used
> > anywhere:
>
> I believe the values that actually get inspected at runtime are the
> tgdeferrable and tginitdeferred fields in pg_trigger. The columns in
> p
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I see the values being stored on constriant creation, but not being used
> anywhere:
I believe the values that actually get inspected at runtime are the
tgdeferrable and tginitdeferred fields in pg_trigger. The columns in
pg_constraint are just copies o
I can reproduce this failure here too. I am actually quite confused
because:
1) I know this deferrable stuff works or used to work
2) I can't find relivant references to
condeferrable/Anum_pg_constraint_condeferrable and
condeferred/Anum_pg_constraint_condeferre
Postgresql 7.3.1 on Linux i386 - but from what I can see it is on all platforms
It seems pg_get_constraintdef does not remember the setting "DEFERRABLE" on a
constraint. This has the effect that it does not show up in psql \d commands, and it
is also *not* included in backups from pg_dump.
Rep
17 matches
Mail list logo
