Alex J. Avriette [EMAIL PROTECTED] writes:
Given on both Solaris (my database server) and OpenBSD (the machine from
which that manpage came from) I can connect to 127.1, I think you must
be mistaken here. What made you think that it isn't supported?
AFAICT, our code simply hands the string off
I just posted my initial release of the Pl/Java stuff on Gborg. The pljava
project is under Postgres tools - Drivers/Interfaces. Read the
org.postgresql.pljava/readme.htm (you find it using the CVS view) for more
info.
---(end of broadcast)---
TIP
Alex J. Avriette said:
On Tue, Jan 06, 2004 at 10:52:19PM -0500, Andrew Dunstan wrote:
4. My personal preference would be that if any change is made it would
be to insist on an unabbreviated dotted quad for ip4. Alternatively,
we
I really think this is the wrong way to approach it. The
[transferring to hackers]
Tom Lane said:
Dennis Bjorklund [EMAIL PROTECTED] writes:
I've implemented function argument names,
I have reviewed and applied this patch, with some editorialization.
Other languages then pl/pgsql should also work to extend, but I've not
looked at that. The
Andrew Dunstan [EMAIL PROTECTED] writes:
Second, you state that this usage is valid. When you first raised the
matter, you were so certain that it was sanctified by standard that you
asked me if I would implement it if you could quote an RFC sanctifying it
(I said yes) and went off to find
On Wed, Jan 07, 2004 at 06:58:37 +0100,
Dennis Björklund [EMAIL PROTECTED] wrote:
ps I've just changed my email name to my real name which is Dennis
Björklund. I did that 5 years ago (still using pine) and got angry mails
back saying that my mails where broken. I hope the todays email
Greg Stark wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Second, you state that this usage is valid. When you first raised the
matter, you were so certain that it was sanctified by standard that you
asked me if I would implement it if you could quote an RFC sanctifying it
(I said yes) and
On Tue, Jan 06, 2004 at 10:52:19PM -0500, Andrew Dunstan wrote:
A few points.
1. clarification of my IRC comment: A quick examination seems to shaw
that we use the native getaddrinfo() where it exists, otherwise we use
our own, which in turn calls inet_ntoa().
2. ip6 has a well defined
Greg Stark wrote:
a.b.c
When a three-part address is specified, the last part shall be interpreted
as a 16-bit quantity and placed in the rightmost two bytes of the network
address. This makes the three-part address format convenient for specifying
Class B
Bruno Wolff III wrote:
On Wed, Jan 07, 2004 at 06:58:37 +0100,
Dennis Bj?rklund [EMAIL PROTECTED] wrote:
ps I've just changed my email name to my real name which is Dennis
Bj?rklund. I did that 5 years ago (still using pine) and got angry mails
back saying that my mails where broken.
Jan Wieck [EMAIL PROTECTED] writes:
So far I was not able to reproduce the problem. If it is what we think,
then it should be possible to reproduce it with just one single DB
connection, no?
The reason it is difficult to reproduce is that when
StrategyInvalidateBuffer puts a dead buffer on
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Yeah, looks like ... but I actually want to have a clean reproduction of
the error before I attempt to fix it.
Well, I can tell you that just running make check over and over isn't
a real efficient way to reproduce the problem. It might work
On Wed, Jan 07, 2004 at 12:53:19PM -0500, Bruce Momjian wrote:
Greg Stark wrote:
a.b.c
When a three-part address is specified, the last part shall be interpreted
as a 16-bit quantity and placed in the rightmost two bytes of the network
address. This makes the
Bruce Momjian wrote:
Greg Stark wrote:
a.b.c
When a three-part address is specified, the last part shall be interpreted
as a 16-bit quantity and placed in the rightmost two bytes of the network
address. This makes the three-part address format convenient for specifying
Tom Lane wrote:
Note that buffer 160 gets cleared twice in this sequence. The second
time, the CDB for 174 gets found, leading to failure when 174 is cleared.
I believe the correct fix is to do CLEAR_BUFFERTAG on the buffer (and
maybe the CDB too?) when returning a buffer to the freelist in
Tom Lane [EMAIL PROTECTED] writes:
It might also be worthwhile to add another BM_FLAG bit that
specifically indicates a buffer is on the freelist, and
set/clear/test that at appropriate spots.
ISTM that BM_FREE should indicate this, or am I misunderstanding you?
-Neil
Neil Conway [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
It might also be worthwhile to add another BM_FLAG bit that
specifically indicates a buffer is on the freelist, and
set/clear/test that at appropriate spots.
ISTM that BM_FREE should indicate this, or am I
Kurt Roeckx wrote:
For getaddrinfo() it says:
If the nodename argument is not null, it can be a descriptive name
or can be an address string. If the specified address family is
AF_INET, [IP6] [Option Start] AF_INET6, [Option End] or AF_UNSPEC,
valid descriptive names include
Title: Message
What API call can I
make to find out if a column is nullable or not?
Dann Corbit wrote:
What API call can I make to find out if a column is nullable or not?
SELECT attnotnull FROM pg_attribute ...
see documentation Internals/System Catalogs
Regards,
Andreas
---(end of broadcast)---
TIP 1: subscribe and
Tom Lane [EMAIL PROTECTED] writes:
It might be a good idea to rename BM_FREE to something else, perhaps
BM_UNPINNED, since I can recall being confused about what it meant
too.
If all it indicates is refcount == 0, ISTM we can just get rid of it
altogether, and just check the shared refcount
On Wed, Jan 07, 2004 at 01:58:54PM -0500, Andrew Dunstan wrote:
I read it to mean that abbreviated forms (via inet_addr()) are OK for
AF_INET but not for AF_INET6 (via inet_pton())
But we use AF_UNSPEC/PF_UNSPEC.
Kurt
---(end of
On Wed, Jan 07, 2004 at 01:58:54PM -0500, Andrew Dunstan wrote:
Kurt Roeckx wrote:
[IP6] [Option Start] If the specified address family is AF_INET6 or
AF_UNSPEC, standard IPv6 text forms described in inet_ntop() are
valid. [Option End]
I read it to mean that abbreviated forms
Kurt Roeckx [EMAIL PROTECTED] writes:
It's a.b.0.c.
Note that the c can be bigger than 255, so 128.1.512 turns into
128.1.2.0. This can make perfect sense when you still used
classes.
Perhaps it'll seem less strange if I restate the rule so there aren't four
different cases:
A dotted
Neil Conway [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
It might be a good idea to rename BM_FREE to something else, perhaps
BM_UNPINNED, since I can recall being confused about what it meant
too.
If all it indicates is refcount == 0, ISTM we can just get rid of it
On Wed, 7 Jan 2004, Bruno Wolff III wrote:
ps I've just changed my email name to my real name which is Dennis
Björklund.
It still isn't legal to use non US ASCII characters in headers. There
is an encoding scheme that can be used for the subject header.
I hoped that pine was going to do
Kurt Roeckx [EMAIL PROTECTED] writes:
I guess I missed that that section is only about IPv6. So it
should use inet_addr()'s behaviour.
Well, the question is still whether *our* code is doing anything wrong,
or whether the blame rests entirely with the complainant's C library.
AFAICT the issue
Greg Stark wrote:
Kurt Roeckx [EMAIL PROTECTED] writes:
It's a.b.0.c.
Note that the c can be bigger than 255, so 128.1.512 turns into
128.1.2.0. This can make perfect sense when you still used
classes.
Perhaps it'll seem less strange if I restate the rule so there aren't four
=?ISO-8859-1?Q?Dennis_Bj=F6rklund?= [EMAIL PROTECTED] writes:
On Wed, 7 Jan 2004, Bruno Wolff III wrote:
ps I've just changed my email name to my real name which is Dennis
Björklund.
It still isn't legal to use non US ASCII characters in headers. There
is an encoding scheme that can be used
On Wed, Jan 07, 2004 at 15:17:26 -0500,
Tom Lane [EMAIL PROTECTED] wrote:
AFAICS, you're sending
From: =?ISO-8859-1?Q?Dennis_Bj=F6rklund?= [EMAIL PROTECTED]
which is an instance of the encoding scheme Bruno mentioned. I have
never heard that it is only supposed to be used in
Kurt Roeckx wrote:
On Wed, Jan 07, 2004 at 01:58:54PM -0500, Andrew Dunstan wrote:
I read it to mean that abbreviated forms (via inet_addr()) are OK for
AF_INET but not for AF_INET6 (via inet_pton())
But we use AF_UNSPEC/PF_UNSPEC.
mode value=language lawyer
Even so, as I read it
I've attached a (gzip'ed) patch that makes the following changes to
the buffer manager:
(1) Overhaul locking; whenever the code needs to modify the state
of an individual buffer, do synchronization via a per-buffer
meta data lock rather than the global BufMgrLock. For more
On Wed, Jan 07, 2004 at 05:37:09PM -0500, Neil Conway wrote:
- if a backend holds the BufMgrLock, it will never try to
LWLockAcquire() a per-buffer meta data lock, due to the risk of
deadlock (and the loss in concurrency if we got blocked waiting
while still holding the
AFAICS, you're sending
From: =?ISO-8859-1?Q?Dennis_Bj=F6rklund?= [EMAIL PROTECTED]
which is an instance of the encoding scheme Bruno mentioned. I have
never heard that it is only supposed to be used in Subject:
... certainly there are a ton of people besides you who use it in From:.
So I
On Thu, Jan 08, 2004 at 09:20:02AM +0800, Christopher Kings-Lynne wrote:
Whether your name is being displayed nicely is a whole 'nother matter.
On my machine I see Dennis Bj-rklund or Dennis Bj rklund depending
on which display I look at :-(. I think this is a font issue, but I
don't have
-Original Message-
From: Andreas Pflug [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 07, 2004 11:17 AM
To: Dann Corbit
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Dumb question: How do I determine
programmatically if a column is nullable?
Dann Corbit wrote:
What API
Dann Corbit [EMAIL PROTECTED] writes:
In other words, I will be passed a SQL query. I don't want to have to
parse it myself.
Rather, I want to know (for the bound columns) if a column is nullable
or not.
Is the functionality available in [for example] libpq?
As of 7.4, see PQftable() and
37 matches
Mail list logo
