Tom,
I don't know if the 'canaveral' prompt had anything to do with it
(maybe it was just the subject line), but I kept thinking of shuttle
disasters, o-rings, and plane crashes reading through this. I won't
claim to understand everything in huge detail, but from this newbie's
point of view, w
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I think it will very likely rename/unlink will fail because of the file
> > descriptor cache kept by each backend.
>
> Hmm ... you're probably right. Okay, it's a more significant issue than
> I thought.
>
> > I am attaching dir.c f
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think it will very likely rename/unlink will fail because of the file
> descriptor cache kept by each backend.
Hmm ... you're probably right. Okay, it's a more significant issue than
I thought.
> I am attaching dir.c from the PeerDirect port. It han
Tom Lane wrote:
> Claudio Natoli <[EMAIL PROTECTED]> writes:
> > One important thing I forgot, that someone could start looking at now:
> > * backends keeping files open when other backends are trying to
> > delete/rename them
>
> > We must do better for the official port,
>
> Why? The procedu
On 25 Jan 2004, Greg Stark wrote:
> expression "a,b". It's "fixed" by just declaring "," special inside function
> calls. If you want to use the operator in the function call you have to use an
> extra set of parentheses.
Well, it would work. It's just that it felt like such a big hack that I
did
Okay ... Chris was kind enough to let me examine the WAL logs and
postmaster stderr log for his recent problem, and I believe that
I have now achieved a full understanding of what happened. The true
bug is indeed somewhere else than slru.c, and we would not have found
it if slru.c had had less-par
I have added these and your later mention of delete/rename of open files
to the Win32 project page:
http://momjian.postgresql.org/main/writings/pgsql/project
---
Claudio Natoli wrote:
>
> > I would like ve
Peter Eisentraut wrote:
Brian Moore wrote:
i feel badly that i have not been able to use any existing
standards. xmlrpc, i found, was not type-rich enough, and that made
it difficult or impossible to use. in particular, the only way to
represent a matrix is as a struct of structs. this makes it
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> 1. What IP is black listed?
actcom.net.il's mail forwarders.
> 2. What spam blocking service is black listinging this IP?
Me personally. I instituted that block about 9 months ago after
deciding that [EMAIL PROTECTED] was an alias for /dev/null; the
Hi Tom,
Sorry for sending this email through a public list. As you can, I think,
understand, I am not able to send you mail directly.
Whenever I try to send you mail directly, I get a bounce like so:
The original message was received at Mon, 26 Jan 2004 02:41:59 +0200
from line102-130.adsl.actc
Greg Stark <[EMAIL PROTECTED]> writes:
> Of course it's ambiguous. Just as f(a,b) is ambiguous in C. It could
> mean call f with two arguments, or it could mean call f with the
> result of the expression "a,b". It's "fixed" by just declaring ","
> special inside function calls. If you want to use t
Greg Stark <[EMAIL PROTECTED]> writes:
> But the compatibility with Oracle would be awfully nice.
Perhaps I'm missing something here: why is compatibility with Oracle
here particularly worth worrying about? Supporting the same
functionality as Oracle is good, but ISTM supporting the exact same
syn
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> On 25 Jan 2004, Greg Stark wrote:
>
> > > > foo (x => 13, y => 42)
> > > >
> >
> > Is it really necessary to steal it?
>
> Yes, it is necessary since the arguments to a function are just
> expressions. If you do not the above would be ambigious
Tom Lane wrote:
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
I kind of like AS also now after thinking about it. The only reason for =>
is that oracle used it, nothing else.
Peter Eisentraut pointed out to me that I'd missed a conflicting feature
in SQL99: that spec uses "value AS type"
IIRC none the patches that made online vacuuming less intrusive were
included in the released 7.4.
Where can I find the "prefferred" patch (preferrably the later one that
yields after vacuumin N pages) for 7.3.4 or 7.4 series.
I currently don't want any other fanciness that was tried as well.
--
> The only question now is if it should be that we call the function with
> the variable x AS the value 13, or if we call the function with 13 AS the
> variable x. I.e.
...
> I don't know if one is more natural then the other in english. To my
> swedish ear both sounds as good. I like (x as 13) a
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> I kind of like AS also now after thinking about it. The only reason for =>
> is that oracle used it, nothing else.
Peter Eisentraut pointed out to me that I'd missed a conflicting feature
in SQL99: that spec uses "value AS type" in some function-call
On Sun, 25 Jan 2004, elein wrote:
> Barring any override from the SQL200x standard,
> I would strongly suggest AS, too.
I kind of like AS also now after thinking about it. The only reason for =>
is that oracle used it, nothing else.
As I wrote in another mail, I will check out sql200x.
> >
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> Are those exposed through the libpq interface?
>>
>> No, because libpq doesn't really have any concept of prepared statements.
>> It would probably make sense to add some more API to libpq to allow
>> creation and interrogation of pre
Greg Stark <[EMAIL PROTECTED]> writes:
>> I've been looking (and coded) a little bit on named function calls.
>> Calls on the form:
>>
>> foo (x => 13, y => 42)
>>
>> Implementing this means that the symbol => no longer can be defined
>> by the user as an operator. It's not used as default in pg,
On 25 Jan 2004, Greg Stark wrote:
> > > foo (x => 13, y => 42)
> > >
>
> Is it really necessary to steal it?
Yes, it is necessary since the arguments to a function are just
expressions. If you do not the above would be ambigious and there is no
clean way to fix that. Say that => is an operat
[EMAIL PROTECTED] (David Fetter) writes:
> In article <[EMAIL PROTECTED]> you wrote:
> >
> > I've been looking (and coded) a little bit on named function calls.
> > Calls on the form:
> >
> > foo (x => 13, y => 42)
> >
> > Implementing this means that the symbol => no longer can be defined
> >
Brian Moore wrote:
> i feel badly that i have not been able to use any existing
> standards. xmlrpc, i found, was not type-rich enough, and that made
> it difficult or impossible to use. in particular, the only way to
> represent a matrix is as a struct of structs. this makes it very
> verbose for
Brian Moore kirjutas P, 25.01.2004 kell 11:07:
> hello,
>
> this note is intended to describe my work on beginning to further
> integrate xml into postgresql. first, i'd like to thank the
> contributers of contrib/xml as their work was instrumental in helping
> me understand what support exists a
Neil Conway wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am seeing the following compile failure in currrent CVS. Seems there
> > is a conflict between readline and psql's use of the xmalloc function
> > name.
>
> This should be fixed in the latest CVS HEAD code (i.e. r1.82 of
> commo
Bruce Momjian wrote:
Bill Moran wrote:
Hey all,
I hope this isn't off-topic or inapropriate to this list ...
I'm not familiar with the PostgreSQL patch-submittal/development cycle.
I recently submitted a patch regarding \copy syntax in psql, and I'd
like to keep an eye on it to see that it gets
Dear all ,
Would like to receive your kind attention and enormous knowledge on the
following
I have a function
sai_func_a()
Which does as follows and in the same order:
1. Retrieves the latest record from the table test_sai
(By latest I mean the record corresponding to max primary key o
Greg Stark wrote:
I do know that AFS returns quota failures on close. This was unusual enough
that when AFS was deployed at school unix tools failed left and right over
precisely this issue. Though it mostly just meant they returned the wrong exit
status.
That means
open();
write();
sync(
In article <[EMAIL PROTECTED]> you wrote:
> I've been looking (and coded) a little bit on named function calls.
> Calls on the form:
>
> foo (x => 13, y => 42)
>
> Implementing this means that the symbol => no longer can be defined
> by the user as an operator. It's not used as default in pg, bu
I've been looking (and coded) a little bit on named function calls. Calls
on the form:
foo (x => 13, y => 42)
Implementing this means that the symbol => no longer can be defined by the
user as an operator. It's not used as default in pg, but I just want to
tell you up front in case you don't l
hello,
this note is intended to describe my work on beginning to further
integrate xml into postgresql. first, i'd like to thank the
contributers of contrib/xml as their work was instrumental in helping
me understand what support exists and where i wanted to go. thanks.
my first requirement is t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am seeing the following compile failure in currrent CVS. Seems there
> is a conflict between readline and psql's use of the xmalloc function
> name.
This should be fixed in the latest CVS HEAD code (i.e. r1.82 of
common.c) -- can you make sure your so
32 matches
Mail list logo
