Tom Lane wrote:
Quite aside from the compatibility and how-useful-is-it-really
arguments, I think this'd be a bad idea in the abstract. SQL is not one
of those languages that assigns semantic significance to the shape of
whitespace [1]. We should NOT introduce any such concept into psql,
becau
Tom Lane wrote:
Michael Glaesemann <[EMAIL PROTECTED]> writes:
What use case are you envisioning? Just saving ... *counts ... 14
keystrokes in this case? (I'm not saying there *isn't* a use case. I
just don't see a big benefit here.)
Quite aside from the compatibility and how-useful-is-it-r
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> What use case are you envisioning? Just saving ... *counts ... 14
> keystrokes in this case? (I'm not saying there *isn't* a use case. I
> just don't see a big benefit here.)
Quite aside from the compatibility and how-useful-is-it-really
argumen
On May 16, 2006, at 13:42 , Joshua D. Drake wrote:
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
What if single line statements that were seperated by ; within
psql were implicitly within a transaction?
Seems like this would risk breaking a lot of scripts.
I wouldn't assum
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
What if single line statements that were seperated by ; within psql were
implicitly within a transaction?
Seems like this would risk breaking a lot of scripts.
I wouldn't assume that it would be a default feature of course. Perhap
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> I'm reworking hierarchical queries and am adding a LEVEL pseudocolumn.
> As it's a totally calculated attribute, what's the best way to handle
> it keeping in mind that LEVEL is only used in a hierarchical query?
Perhaps you should start by explaini
As Qingqing Zhou said, i misread "exist".
Thanks.
- Original Message -
From: "Gurjeet Singh" <[EMAIL PROTECTED]>
To: "ipig" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, May 16, 2006 11:36 AM
Subject: Re: [HACKERS] Why use " != "
It done so, because InitProcess() is supposed to be calle
[EMAIL PROTECTED] wrote:
> The real question - and I believe Tom and others have correctly harped
> on it in the past is - is it worth it? Until somebody actually pulls
> up their sleeves, invests a month or more of their life to it, and
> does it, we really won't know. And even then, the cost of m
Oh come on, Sorry to troll but this is too easy.
On 5/15/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
You guys have to kill your Windows hate - in jest or otherwise. It's
zealous, and blinding.
[snip]
Why would it
be assumed, that a file system designed for use from a desktop, would be
op
"Gurjeet Singh" <[EMAIL PROTECTED]> writes:
> I don't think Cristiano is asking for the schema_name in the
> EXPLAIN o/p. The request is for the table ALIASes to be shown in the
> o/p, which makes more sense than schema_name+table_name, since the
> same table can be used in the same query more
I don't think Cristiano is asking for the schema_name in the
EXPLAIN o/p. The request is for the table ALIASes to be shown in the
o/p, which makes more sense than schema_name+table_name, since the
same table can be used in the same query more than once.
Gurjeet.
On 5/15/06, Jim C. Nasby <[EMA
On Mon, May 15, 2006 at 05:42:53PM -0700, Joshua D. Drake wrote:
> >Windows98? No, those decisions predate any thought of running Oracle
> >on Windows, probably by decades. But I think the thought process was
> >about as above whenever they did make it; they were running on some
> >pretty stupid
It done so, because InitProcess() is supposed to be called only
once per backend, because it allocates a PGPROC from a LIST OF free
PGPROCs.
So with this test, and calling elog( ERROR, ... ) we are stopping
the caller from doing a second initialization for this backend.
On 5/16/06, ipig <[
""ipig"" <[EMAIL PROTECTED]> wrote
>
>in postgresql-8.1.3/src/backend/storage/lmgr/proc.c
>there are 2 function InitProcess and InitDummyProcess, both use
> " if (MyProc != NULL)
> elog(ERROR, "you already exist"); " (line 215 and 315)
>
>why use " != " ?
>
I guess you misread "
""Joshua D. Drake"" <[EMAIL PROTECTED]> wrote
>
> What if single line statements that were seperated by ; within psql were
> implicitly within a transaction?
>
> E.g;
>
> postgres=# select * from foo; update foo set bar = 'baz'; delete from
bing;
>
> Would be a single transaction ? The begin/commi
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> What if single line statements that were seperated by ; within psql were
> implicitly within a transaction?
Seems like this would risk breaking a lot of scripts.
regards, tom lane
---(end of broadcas
Hello,
I was dinking around wand came across something that may (or may not be
useful).
What if single line statements that were seperated by ; within psql were
implicitly within a transaction?
E.g;
postgres=# select * from foo; update foo set bar = 'baz'; delete from bing;
Would be a sin
Having tinkered a little with PQA, yes, actually. The issue is that the
"message" text can easily be multi-line and contain a vast variety of
special characters. The issue is figuring out where the prefix, the tag
and the message begin and end. And our text log format makes that a PITA.
Try
Hi,
in postgresql-8.1.3/src/backend/storage/lmgr/proc.c
there are 2 function InitProcess and
InitDummyProcess, both use
" if (MyProc != NULL) elog(ERROR,
"you already exist"); " (line 215 and 315)
why use " != " ?
Best regards.
Tom Lane wrote:
Ron Mayer <[EMAIL PROTECTED]> writes:
I think the real reason Oracle and others practically re-wrote
their own VM-system and filesystems is that at the time it was
important for them to run under Windows98; where it was rather
easy to write better filesystems than your customer's
Ron Mayer <[EMAIL PROTECTED]> writes:
> I think the real reason Oracle and others practically re-wrote
> their own VM-system and filesystems is that at the time it was
> important for them to run under Windows98; where it was rather
> easy to write better filesystems than your customer's OS was
> b
Jim C. Nasby wrote:
There's an fadvise that tells the OS to compress the data if it actually
makes it to disk?
Compressed-filesystem extension (like e2compr, and I think either
Fat or NTFS) can do that.
I think the reasons against adding this feature to postgresql are
largely the same as the
Ühel kenal päeval, E, 2006-05-15 kell 17:21, kirjutas Tom Lane:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> >> Sven Suursoho wrote:
> >>> As for testing in actual pl/python build environment, we had objections
> >>> from
> >>> leading postgresql Tom Lane that even if we do test it at build time
Hannu Krosing <[EMAIL PROTECTED]> writes:
>> Sven Suursoho wrote:
>>> As for testing in actual pl/python build environment, we had objections
>>> from
>>> leading postgresql Tom Lane that even if we do test it at build time,
>>> a determined DBA may substitute a buggy python.so later and still c
Sorry for cross-posting, but this IS a cross-platform issue.
Christian Tismer tismer at stackless.com wrote:
> Sven Suursoho wrote:
>
> >>> Is there any way to rewrite following program to handle returned
> >>> generator without hitting this bug?
>
> The only way I can think of getting aroun
On Mon, May 15, 2006 at 10:09:47PM +0200, Martijn van Oosterhout wrote:
> > In this case the problem is that we want to tell the OS "Hey, if this
> > stuff is actually going to go out to the spindles then compress it. And
> > by the way, we won't be doing any random access on it, either." But
> > A
On Mon, May 15, 2006 at 03:02:07PM -0500, Jim C. Nasby wrote:
> The problem is that it seems like there's never enough ability to clue
> the OS in on what the application is trying to accomplish. For a long
> time we didn't have a background writer, because the OS should be able
> to flush things o
On Mon, May 15, 2006 at 03:44:50PM -0400, Andrew Dunstan wrote:
> Jim C. Nasby wrote:
> >On Mon, May 15, 2006 at 02:18:03PM -0400, Tom Lane wrote:
> >
> >>"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> >>
> >>>A recent post Tom made in -bugs about how bad performance would be if we
> >>>spilled
Jim C. Nasby wrote:
On Mon, May 15, 2006 at 02:18:03PM -0400, Tom Lane wrote:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
A recent post Tom made in -bugs about how bad performance would be if we
spilled after-commit triggers to disk got me thinking... There are
several operations the dat
On Mon, May 15, 2006 at 02:18:03PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > A recent post Tom made in -bugs about how bad performance would be if we
> > spilled after-commit triggers to disk got me thinking... There are
> > several operations the database performs tha
On Mon, May 15, 2006 at 12:37:34PM -0400, Douglas McNaught wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>
> > On Mon, May 15, 2006 at 10:55:43AM -0500, Hogan, James F. Jr. wrote:
> >> Only specific tables.
> >>
> >> Of the 150 plus existing there are only 8 or 10 that hold sensitive
> >> d
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> A recent post Tom made in -bugs about how bad performance would be if we
> spilled after-commit triggers to disk got me thinking... There are
> several operations the database performs that potentially spill to disk.
> Given that any time that happens we
On Wed, May 10, 2006 at 08:46:41PM +0200, Zdenek Kotala wrote:
> I would like to implement following item from TODO list:
> * Allow commenting of variables in postgresql.conf to restore them to
> defaults. Currently, if a variable is commented out, it keeps the
> previous uncommented value until a
Moving to -hackers
On Wed, May 10, 2006 at 11:26:30AM -0300, Cristiano Duarte wrote:
> > Don't know whether this would help in your situation, but you can make the
> > output of EXPLAIN disambiguous by using table aliases:
> >
> > EXPLAIN
> > SELECT *
> >FROM schema1.mytable AS mt1, schema2.
A recent post Tom made in -bugs about how bad performance would be if we
spilled after-commit triggers to disk got me thinking... There are
several operations the database performs that potentially spill to disk.
Given that any time that happens we end up caring much less about CPU
usage and much m
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Mon, May 15, 2006 at 10:55:43AM -0500, Hogan, James F. Jr. wrote:
>> Only specific tables.
>>
>> Of the 150 plus existing there are only 8 or 10 that hold sensitive
>> data.
>
> In that case I'd definately go with the suggestion of creating access
>
On Mon, May 15, 2006 at 10:55:43AM -0500, Hogan, James F. Jr. wrote:
> Only specific tables.
>
> Of the 150 plus existing there are only 8 or 10 that hold sensitive
> data.
In that case I'd definately go with the suggestion of creating access
functions and logging to a table from within them. Jus
Only specific tables.
Of the 150 plus existing there are only 8 or 10 that hold sensitive
data.
This will grow over time but will always be in the minority.
-Original Message-
From: Jim C. Nasby [mailto:[EMAIL PROTECTED]
Sent: Monday, May 15, 2006 10:42 AM
To: Hogan, James F. Jr.
Cc
On 5/15/06, Tom Lane <[EMAIL PROTECTED]> wrote:
This could only work if LEVEL is guaranteed to have one and only one
value per tuple. I'm not too sure about the spec but it seems like
that'd probably fall down in join situations.
Yes, this was another thing handled by Evgen's patch... FakeVar
Martijn van Oosterhout writes:
> All you need to do is decide where you are going to store the level
> number and add it as a system attribute (negative attribute number).
This could only work if LEVEL is guaranteed to have one and only one
value per tuple. I'm not too sure about the spec but it
How do you hope to avoid this overhead when you're looking to track
information on every single SELECT statement? Or were you looking to
only log access to some specific tables?
On Mon, May 15, 2006 at 09:38:54AM -0500, Hogan, James F. Jr. wrote:
> Thank you all for the effort you put into respons
Mark Campbell wrote:
> Hi All
>
> I downloaded version 7.3 and compiled that.
>
> First I had to compile newer versions of "m4" and "bison"
>
> At least I now have an up and running postgres server
>
> Thanks for all the help
>
> Mark Campbell
>
>
> Confidentiality Notice: http://ucs.co.za/c
On Mon, May 15, 2006 at 11:17:41AM -0400, Jonah H. Harris wrote:
> On 5/15/06, Martijn van Oosterhout wrote:
> >tableoid is a pseudo-column like you mean, perhaps you should look how
> >that works.
>
> I thought tableoid was a system column with a physical representation
> on the tuple itself? I
On 5/15/06, Martijn van Oosterhout wrote:
tableoid is a pseudo-column like you mean, perhaps you should look how
that works.
I thought tableoid was a system column with a physical representation
on the tuple itself? I don't want any on-disk representation of my
pseudocolumn... just assigned a
On Mon, May 15, 2006 at 11:03:46AM -0400, Jonah H. Harris wrote:
> I couldn't think of any pseudocolumns like this in PostgreSQL, but I
> may just be brain-dead again. As it may be sorta similar, how were we
> discussing handling rownum?
tableoid is a pseudo-column like you mean, perhaps you shou
Hey everyone,
I'm reworking hierarchical queries and am adding a LEVEL pseudocolumn.
As it's a totally calculated attribute, what's the best way to handle
it keeping in mind that LEVEL is only used in a hierarchical query?
Looking at Evgen's patches, if he recognizes a hierarchical query and
fin
Thank you all for the effort you put into response.
The biggest thing I want to avoid isn't so much having to parse through
the log files but to avoid turning on such extensive logging altogether.
I am not sure what kind of additional load logging to this extent may
add.
Looks like I am not goin
47 matches
Mail list logo
