On 28 Jul 2003 at 9:56, Alvaro Herrera wrote:
> On Mon, Jul 28, 2003 at 02:29:36PM +0530, Shridhar Daithankar wrote:
>
> > I was just wondering over it. This is for difference between vacuum full and
> > vacuum analyze. Can somebody enlighten,
>
> Actually, the different concepts are "lazy vacu
On 29 Jul 2003 at 12:48, Andreas Jung wrote:
> On Tue, 2003-07-29 at 12:42, Shridhar Daithankar wrote:
> > On 29 Jul 2003 at 12:33, Andreas Jung wrote:
> > > we are running Postgres 7.3.3 successfully on our portal sites
> > > under Solaris. For a new project we have the requirement that
> > > N p
On 29 Jul 2003 at 13:07, Andreas Jung wrote:
> On Tue, 2003-07-29 at 13:02, Shridhar Daithankar wrote:
> > On 29 Jul 2003 at 12:48, Andreas Jung wrote:
> > > Our experience was that the complete table has been locked (Solaris)
> > > but row-level locking was working with Linux.
> >
> > Whoa!! Tha
Tom Lane writes:
> Clients could probably still make use of server_encoding, though I'm
> unclear on what they'd use it for now, let alone then. ISTM
> client_encoding is the only setting the client need deal with directly.
Then why did we add a GUC variable "server_encoding" at all?
--
Peter
Joe Conway wrote:
> > Do you think there would be any use for an aggregate which returns
an
> > array of the aggregated (usually simple) type?
>What exactly have you looked at? In current cvs there is array_append
>and array_cat. There *was* array_accum, but that was yanked due to an
>objectio
Is 7.3.4 a done deal now? If so, the front page of the Pg web site needs
to refer to it (still refers to 7.3.3 press release).
cheers
andrew
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgre
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Then why did we add a GUC variable "server_encoding" at all?
The JDBC guys wanted to know it. Why is not clear to me, but I figured
it was easy enough to make them happy.
regards, tom lane
---(end of
On Tue, 2003-07-29 at 09:50, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Then why did we add a GUC variable "server_encoding" at all?
>
> The JDBC guys wanted to know it. Why is not clear to me, but I figured
> it was easy enough to make them happy.
It could still be usefu
Hello:
The JDBC guys wanted to know it. Why is not clear to me, but I figured
it was easy enough to make them happy.
I'm using it too in my .NET Data Provider for allow atomatic encoding of
strings before send it to the server.
--
Best regards
Carlos Guzmán Álvarez
Vigo-Spain
Merlin Moncure wrote:
What do you think about the other question about an
'array creating aggregate', is that a useful contribution?
Hmm, either I'm not understanding you, or you're not understanding me ;-)
First, see contrib/intagg.
Second, the following works in 7.4devel:
-- create test data for
Yes, it is a done deal. I'm in the process of updating the main web site
and the sourceforge site, hopefully I'll be done sometime this morning.
Robert Treat
On Tue, 2003-07-29 at 09:17, Andrew Dunstan wrote:
>
> Is 7.3.4 a done deal now? If so, the front page of the Pg web site needs
> to re
On Mon, 2003-07-28 at 02:47, Philip Yarra wrote:
> On Mon, 28 Jul 2003 04:27 pm, [EMAIL PROTECTED] wrote:
> > Just part of the baptism of fire for a newbie, I guess. :-)
>
> I've found the learning curve pretty steep too. Is it worth putting together
> some of these 'gotchas' into a neophyte-deve
A more ambitious project, and one which seems to me worthwhile, would be
a descriptive tour of the source code and data structures. Something
larger than an FAQ and (one hopes) smaller than a book. The existence of
such things is useful in bootstrapping newbies (like me) in Linux kernel
stuff,
Merlin Moncure wrote:
Dear hackers,
Do you think there would be any use for an aggregate which returns an
array of the aggregated (usually simple) type? Has this already been
done by anyone? I looked at the source and noticed that for each
inserted item, the array utility functions perfor
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> A more ambitious project, and one which seems to me worthwhile, would be
> a descriptive tour of the source code and data structures.
Have you looked at Bruce's presentations? There are a couple of sets of
slides available from http://developer.postgr
We're testing application with Postgres 7.3.2 on the backend.
The entire test involves running series of individual tests.
Few times throughout this procedure the database server is being
shut down and started up again
Normally, this is what I see in the database log.
2003-07-29 10:14:33 [14513]
Michael Brusser <[EMAIL PROTECTED]> writes:
> Now, (on Linux only) we sometimes run into this:
> 2003-07-29 11:31:15 [26665] LOG: smart shutdown request
> 2003-07-29 11:31:15 [26728] LOG: shutting down
> 2003-07-29 11:31:17 [26728] LOG: database system is shut down
> 2003-07-29 11:31:19 [267
It's in the SQL99 standard. There's nothing forcing you to use them - I
am a (possibly) old-fashioned data architect, so I never use them ;-)
SQL99 actually allows you to use more or less arbitrary composite types
as columns (although Pg currently doesn't) - many would argue that this
violates
Yes, I agree they are very useful, although not quite as detailed as
what I had in mind.
andrew
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
A more ambitious project, and one which seems to me worthwhile, would be
a descriptive tour of the source code and data structures.
Andrew wrote:
> It's in the SQL99 standard. There's nothing forcing you to use them -
I
> am a (possibly) old-fashioned data architect, so I never use them ;-)
> SQL99 actually allows you to use more or less arbitrary composite
types
> as columns (although Pg currently doesn't) - many would argu
well, (smile) I didn't say *I* saw violation of FNF as an objection. I
think my statement is true - many would see it as a violation of FNF.
Many others like you might argue differently.
I first got into this business nearly 20 years ago when I came to
realise the severe limitations of the rela
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am seeing the following parallel regression test failures. Any idea
> on the cause?
For the record, I believe this is explained by the bug I just fixed in
_bt_search().
The bug occurs only when one backend is trying to search a btree index
at the sam
Andreas Jung <[EMAIL PROTECTED]> writes:
> On Tue, 2003-07-29 at 13:02, Shridhar Daithankar wrote:
>>> Our experience was that the complete table has been locked (Solaris)
>>> but row-level locking was working with Linux.
>>
>> Whoa!! That's something. How did you conclude it is locked. If you can
Tom Lane wrote:
> We need to think about whether this bug is serious enough to justify a
> quick 7.3.5 release. I'm leaning to the idea that it is not, because
> if it were, we'd have heard about it from the field before now. In
> pre-7.4 code there is only one instant in the lifespan of an index
Hi guys,
I hear that we're supposed to use the 'bin' versions of the 'src' columns
where possible. I would like then to use them in phpPgAdmin for displaying
defaults and stuff. Is there some way to use them from SQL? Cos it all
looks like garbage to me :)
Chris
---(en
On Tue, 2003-07-29 at 21:45, Christopher Kings-Lynne wrote:
> Hi guys,
>
> I hear that we're supposed to use the 'bin' versions of the 'src' columns
> where possible. I would like then to use them in phpPgAdmin for displaying
> defaults and stuff. Is there some way to use them from SQL? Cos it a
Going from precision 3 down to 0 - note the bug in (1). It always displays
a trailing zero.
australia=# select current_timestamp(3);
timestamptz
2003-07-30 10:54:55.642+08
(1 row)
australia=# select current_timestamp(2);
timestamptz
-
[ CC to Kurt and Steven on bsdi list.]
Guys, I just replied to this email on the BSDi email list. The issue is
that someone found that some(most?) IDE drives have write cache enabled,
though the drives do not preserve the write cache data on power failure.
I am surprised we have not heard of th
28 matches
Mail list logo
