On Mon, Apr 09, 2001 at 11:41:55AM -0700, Henry B. Hotz wrote:
At 1:50 AM -0400 4/6/01, Tom Lane wrote:
...
What version of libreadline do you have installed, and how does it
declare completion_matches()?
I have whatever is standard on NetBSD 1.5. I noticed that configure
found a
Is there an easy way to read the WAL files generated by Postgres? I'm
looking into writting a replication deamon for postgres and think that
the WAL files are the best way to know what has happened to the db and
what has to be replicated. I have a roughed out idea of how to code it
up but the
Is there an easy way to read the WAL files generated by Postgres? I'm
looking into writting a replication deamon for postgres and think that
the WAL files are the best way to know what has happened to the db and
what has to be replicated. I have a roughed out idea of how to code it
up but
It's nothing but unused definitions. PostgreSQL7.1 compiles and works for me.
I got following warnings for PL/PgSQL
make[2]: `/opt/rh7/postgresql/postgresql-7.1/src/pl'
make[3]: `/opt/rh7/postgresql/postgresql-7.1/src/pl/plpgsql'
make -C src all
make[4]:
I am trying to add another authentication mechanism to PostgreSQL... And,
in doing that, I need to verify the existance of an user within PG. Short
of hacking together code from verify_password(), is there any way to check
if a user exists in postgresql? (The actuall password verification will
AFAIK we never actually *had* IPV6 support in those datatypes, only
stubs for it.
the inet_net_pton implementation that was brought in from BIND had its
IPv6 portions scrubbed. micro-over-optimization of the contributed
bitncmp caused the ipv4 as int assumption to reoccur. i'm going to
have
Paul A Vixie [EMAIL PROTECTED] writes:
my original CIDR type implementation used BIND's inet_ntop() and inet_pton()
which therefore included latent support for ipv6. it wouldn't take a huge
amount of effort to bring this back, would it?
AFAIK we never actually *had* IPV6 support in those
my original CIDR type implementation used BIND's inet_ntop() and inet_pton()
which therefore included latent support for ipv6. it wouldn't take a huge
amount of effort to bring this back, would it?
(the user below is using VARCHAR for his ip addresses for this reason.)
--- Forwarded