"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(
> -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:
>
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
> >do
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 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
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
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.
Even so, as I read it an IP6 address must follow
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
=?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 th
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 t
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 iss
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
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 i
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
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
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 broadcast)
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 refcoun
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 unsubscri
Title: Message
What API call can I
make to find out if a column is nullable or not?
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 host
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 mi
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
--
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
Stra
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
C
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 make
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 wor
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
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 whe
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 n
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 de
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) an
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
"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
[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 tha
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
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" <[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 stri
37 matches
Mail list logo
