On Mon, Jan 14, 2008 at 10:45:28PM -0500, Tom Lane wrote:
> Jeff Cohen <[EMAIL PROTECTED]> writes:
> > In the proposed solution, hash and list partitions work for all types
> > that support an equality operator, and range partitions work for all
> > types that support fully-ordered comparison.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 17 Jan 2008 20:34:07 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > Are you picturing adding ALTER TABLE commands to set autovacuum
> > parameters?
>
> Well, as I said, I was trying to think of an ap
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 17 Jan 2008 21:43:46 -0300
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > All this thread is a waste of time. We've previously agreed that
> > > we're going to store autovacuum
Gregory Stark <[EMAIL PROTECTED]> writes:
> Are you picturing adding ALTER TABLE commands to set autovacuum
> parameters?
Well, as I said, I was trying to think of an appropriate user-visible
API, which I didn't think that pg_autovacuum itself could become.
Further downthread Alvaro points out th
"Tom Lane" <[EMAIL PROTECTED]> writes:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> You are offering what appears to be a "solution". A perfectly valid one
>> in fact. Which one is going to get done first? Which one is going to
>> provide immediate benefit?
>
> The problem is that your "imm
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > All this thread is a waste of time. We've previously agreed that we're
> > going to store autovacuum per-table settings in pg_class.reloptions.
>
> I had forgotten that discussion. So the plan is for the pg_autovacuum
> catalog to
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> All this thread is a waste of time. We've previously agreed that we're
> going to store autovacuum per-table settings in pg_class.reloptions.
I had forgotten that discussion. So the plan is for the pg_autovacuum
catalog to go away entirely, correct?
All this thread is a waste of time. We've previously agreed that we're
going to store autovacuum per-table settings in pg_class.reloptions.
That automatically gives it pg_dump support, and moreover it means the
user needs not set the options that he/she doesn't want to change from
defaults.
--
A
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> You are offering what appears to be a "solution". A perfectly valid one
> in fact. Which one is going to get done first? Which one is going to
> provide immediate benefit?
The problem is that your "immediate benefit" is to encourage people
to do dir
Quoting Tom Lane <[EMAIL PROTECTED]>:
> Mischa Sandberg <[EMAIL PROTECTED]> writes:
> > I'm going to skip the kill(1,0) test and depend on nattch only,
> > with a function that PGSharedMemoryIsInUse() can also use.
> > (For a healthy server, nattch is never less than 2, right?)
>
> Oh, forgot to
Mischa Sandberg <[EMAIL PROTECTED]> writes:
> I'm going to skip the kill(1,0) test and depend on nattch only,
> with a function that PGSharedMemoryIsInUse() can also use.
> (For a healthy server, nattch is never less than 2, right?)
Oh, forgot to mention: healthy servers are not the point here.
Yo
Hope Ho <[EMAIL PROTECTED]> writes:
> We know that PostgreSQL is famous for its good modularity, which allows
> users to select which part they need. It also allow developers to easily
> replace one part without affecting other parts. However, as I know, most
> database engine, like MySQL,
Hope Ho wrote:
> Dear all,
>
> I have some questions about PostgreSQL's modularity. We know that
> PostgreSQL is famous for its good modularity, which allows users to
> select which part they need. It also allow developers to easily replace
> one part without affecting other parts. However,
Mischa Sandberg <[EMAIL PROTECTED]> writes:
> If anyone is interested in creating hung backends, you can
> create a named pipe, and tell the server to COPY from it.
That won't create a problematic situation though, until/unless you
SIGQUIT the parent postmaster.
Personally I think of this as "wha
Dear all,
I have some questions about PostgreSQL's modularity.
We know that PostgreSQL is famous for its good modularity, which allows
users to select which part they need. It also allow developers to easily
replace one part without affecting other parts. However, as I know, most
database
Quoting Stephen Frost <[EMAIL PROTECTED]>:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
> > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > > Easiest fix: change the UID of the user running the postmaster
> (ie. pgsql) so
> > > that each runs as a distinct UID (instead of distinct PGPORT) ...
> been
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 17 Jan 2008 17:38:57 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > Your objection is let's keep it as difficult as possible within the
> > existing paradigm because nobody thought pg_autovacuum c
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Your objection is let's keep it as difficult as possible within the
> existing paradigm because nobody thought pg_autovacuum could be useful
> in the first place.
No, my point is that there's no value in putting band-aids on an object
that was never
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 17 Jan 2008 17:13:52 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> wrote:
> > There are two things here. One having a default value 8.2 currently
> > doesn't
>
> I'm
>>> On Thu, Jan 17, 2008 at 1:35 PM, in message
<[EMAIL PROTECTED]>, "Kevin Grittner"
<[EMAIL PROTECTED]> wrote:
On Thu, Jan 17, 2008 at 12:30 PM, in message <[EMAIL PROTECTED]>,
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>>> I see this didn't make
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Thursday, January 17, 2008 13:58:36 + Dave Page
<[EMAIL PROTECTED]>
wrote:
> On 17/01/2008, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>>
>> Cc:
>> "[EMAIL PROTECTED]@postgresql.org.pgadmin-suppo
>> [EMAIL PROTECTED]@[EMAIL PROTECTED]
>>
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
> There are two things here. One having a default value 8.2 currently
> doesn't
I'm not really convinced by this argument. pg_autovacuum was never
designed to be user-friendly; it is designed to be the back end st
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 17 Jan 2008 16:54:47 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> > - -1? That way by default it will use the settings in
> > postgresql.conf?
>
> Surely we're not going to force initdb for that.
I didn't realize it would take that so sure le
>>> On Wed, Jan 16, 2008 at 5:20 PM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> 2. Make ALTER INDEX RENAME automatically rename the constraint, too.
> 3. Invent an ALTER TABLE RENAME CONSTRAINT command, and have it also
> rename the underlying index.
> I'm thinking
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Can we by default set vac_cost_limit and vac_cost_delay have a DEFAULT
> - -1? That way by default it will use the settings in postgresql.conf?
Surely we're not going to force initdb for that.
> Secondly can we set the default for freeze_min_age to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
Table "pg_catalog.pg_autovacuum"
Column | Type | Modifiers
- --+-+---
vacrelid | oid | not null
enabled | boolean | not null
vac_base_thresh | integer | not null
vac_
Decibel! <[EMAIL PROTECTED]> writes:
> On Jan 16, 2008, at 5:20 PM, Tom Lane wrote:
>> There seem to be three things we could do:
>>
>> 1. Make ALTER INDEX RENAME fail if the index belongs to a constraint.
>> This is trivial code-wise, but doesn't seem especially helpful to
>> users.
> +1. IMO,
Pavel,
Speaking as someone who does lots of PL/pgSQL, CASE would be *great*.
Especially for triggers.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropr
On Jan 16, 2008, at 5:20 PM, Tom Lane wrote:
There was some discussion last week on -bugs about how renaming an
index
that belongs to a unique or primary key constraint is allowed, but can
lead to situations that can't be dumped/restored properly. This isn't
really pg_dump's fault, IMHO. We s
On Jan 16, 2008, at 8:07 AM, Gokulakannan Somasundaram wrote:
gokul=# explain analyze select count(1) from dd;
LOG: EXECUTOR STATISTICS
DETAIL: ! system usage stats:
! 0.277208 elapsed 0.275457 user 0.000148 system sec
! [1.128422 user 0.004976 sys total]
!
On Jan 18, 2008 3:19 AM, Pavel Stehule <[EMAIL PROTECTED]> wrote:
> > Isn't there a danger of syntactical conflict with the SQL SELECT ... CASE
> > statement?
>
> no, isn't. SELECT CASE can be only in expression .. inside SQL
> statement, but PL/SQL CASE is PL statement. These are two different
> w
>>> On Thu, Jan 17, 2008 at 12:30 PM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> I see this didn't make it into 8.3RC1. Will it be in the 8.3.0 release?
>
> You mean this patch?
> http://archives.postgresql.org/pgsql-comm
> If primary goal is ANSI SQL conformance shouldn't we be focusing on
> pl/psm not plpgsql? (yes I am aware they are similar syntatically)
I am not sure if in 8.4 will be space for changes in PL interprets. I
expect so plpgsql will be main SQL language next two years. I don't
plan any big changes
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> I see this didn't make it into 8.3RC1. Will it be in the 8.3.0 release?
You mean this patch?
http://archives.postgresql.org/pgsql-committers/2008-01/msg00151.php
regards, tom lane
---(end of broadcast
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 17 Jan 2008 12:44:41 -0500 (EST)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> pl/PgSQL already is aimed at being Oracle compatible so why complain
> that the author wants to use Oracle syntax if possible. If you don't
> care, that is fine, but
Joshua D. Drake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Thu, 17 Jan 2008 17:43:45 +0100
> "Pavel Stehule" <[EMAIL PROTECTED]> wrote:
>
> > we develop PostgreSQL, but why create own syntax for all? Why? Only so
> > we develop PostgreSQL? We have different implementation and
On Jan 17, 2008 12:08 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> > Primary goal is ANSI SQL conformance (for me). Current PL/pgSQL isn't
> > compatible and it will not be compatible in future (we have different
> > implementation of SRF and really specific implementation of OUT
> > parameters
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 17 Jan 2008 18:00:21 +0100
"Pavel Stehule" <[EMAIL PROTECTED]> wrote:
> Primary goal is ANSI SQL conformance (for me). Current PL/pgSQL isn't
> compatible and it will not be compatible in future (we have different
> implementation of SRF and r
>
> A. I could give flying donkey butt about being the Oracle-Compatible
> community.
>
> B. That "SWITCH" may be an alternate syntax because 15 years ago when I
> took a CS class and I did one chapter of C they had a SWITCH statement
> that resembles CASE.
>
Primary goal is ANSI SQL conformance (
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 17 Jan 2008 17:43:45 +0100
"Pavel Stehule" <[EMAIL PROTECTED]> wrote:
> we develop PostgreSQL, but why create own syntax for all? Why? Only so
> we develop PostgreSQL? We have different implementation and different
> limit, but why create diff
>
> I'm sorry I thought we were developing PostgreSQL.
>
we develop PostgreSQL, but why create own syntax for all? Why? Only so
we develop PostgreSQL? We have different implementation and different
limit, but why create different syntax, I don't understand. It's like
Microsoft. Lot of things are l
>>> On Mon, Jan 7, 2008 at 9:01 AM, in message
<[EMAIL PROTECTED]>, "Kevin Grittner"
<[EMAIL PROTECTED]> wrote:
On Sun, Jan 6, 2008 at 7:20 PM, in message <[EMAIL PROTECTED]>,
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>>> There was a serious perf
Joshua D. Drake wrote:
On Thu, 17 Jan 2008 11:11:42 -0500
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
That would surely defeat the whole point of having this. We want to
have the same syntax as PL/SQL, not different syntax for the same
things.
I'm sorry I thought we were developing Po
On 17/01/2008, Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-01-17 at 16:01 +0100, Pavel Stehule wrote:
>
> > I found so PL/SQL support CASE statement
> > http://download-east.oracle.com/docs/cd/B10500_01/appdev.920/a96624/04_struc.htm#484
> >
> > I propose add this statement to PL/pgSQL to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 17 Jan 2008 16:18:56 +
Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-01-17 at 16:01 +0100, Pavel Stehule wrote:
>
> > I found so PL/SQL support CASE statement
> > http://download-east.oracle.com/docs/cd/B10500_01/appdev.920/a96624
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 17 Jan 2008 11:11:42 -0500
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
> That would surely defeat the whole point of having this. We want to
> have the same syntax as PL/SQL, not different syntax for the same
> things.
I'm sorry I thought we
On 17/01/2008, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> Josh Berkus wrote:
> > Pavel,
> >
> >> I propose add this statement to PL/pgSQL too.
> >
> > Isn't there a danger of syntactical conflict with the SQL SELECT ... CASE
> > statement?
> >
> > I'd love to have CASE in PL/pgSQL, but I always t
Hello
>
> Isn't there a danger of syntactical conflict with the SQL SELECT ... CASE
> statement?
>
no, isn't. SELECT CASE can be only in expression .. inside SQL
statement, but PL/SQL CASE is PL statement. These are two different
worlds. SELECT CASE is invisible for pl parser, because pl parser
s
On Thu, 2008-01-17 at 16:01 +0100, Pavel Stehule wrote:
> I found so PL/SQL support CASE statement
> http://download-east.oracle.com/docs/cd/B10500_01/appdev.920/a96624/04_struc.htm#484
>
> I propose add this statement to PL/pgSQL too.
Please don't post links to potentially copyrighted works.
W
Joshua D. Drake wrote:
Josh Berkus wrote:
Pavel,
I propose add this statement to PL/pgSQL too.
Isn't there a danger of syntactical conflict with the SQL SELECT ...
CASE statement?
I'd love to have CASE in PL/pgSQL, but I always thought that stood in
the way.
Could it be called SWIT
Josh Berkus wrote:
Pavel,
I propose add this statement to PL/pgSQL too.
Isn't there a danger of syntactical conflict with the SQL SELECT ... CASE
statement?
I'd love to have CASE in PL/pgSQL, but I always thought that stood in the way.
Could it be called SWITCH instead?
Joshua D. Drake
Josh Berkus wrote:
Pavel,
I propose add this statement to PL/pgSQL too.
Isn't there a danger of syntactical conflict with the SQL SELECT ... CASE
statement?
I'd love to have CASE in PL/pgSQL, but I always thought that stood in the way.
It should be possible to disambiguate t
Pavel,
> I propose add this statement to PL/pgSQL too.
Isn't there a danger of syntactical conflict with the SQL SELECT ... CASE
statement?
I'd love to have CASE in PL/pgSQL, but I always thought that stood in the way.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---
Hello
I found so PL/SQL support CASE statement
http://download-east.oracle.com/docs/cd/B10500_01/appdev.920/a96624/04_struc.htm#484
I propose add this statement to PL/pgSQL too.
Reasons:
a) it's useful construct,
b) this statement is defined in SQL/PSM - better conformance with ANSI
Implementa
* Tom Lane ([EMAIL PROTECTED]) wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > Easiest fix: change the UID of the user running the postmaster (ie. pgsql)
> > so
> > that each runs as a distinct UID (instead of distinct PGPORT) ... been
> > doing
> > this since moving to FreeBSD 6.x .
On 17/01/2008, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>
> Cc: "[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL
> PROTECTED]@postgresql.org.pgsql-chat"@post
>
> Hey, this is exactly the sort of weird "Cc:" line I saw in the recent
> spam surge. Since I suspect you are using the new
Cc: "[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL
PROTECTED]@postgresql.org.pgsql-chat"@post
Hey, this is exactly the sort of weird "Cc:" line I saw in the recent
spam surge. Since I suspect you are using the news server to post, I
suggest you take a long and careful look at the
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Perhaps the easiest thing to do is to create a (possibly dangling)
> > symlink in /tmp to the real socket in a protected dir.
>
> Cute idea ...
>
> > One thing to be aware of is /tmp cleaners ...
>
> ... but that would definitely b
Tom Lane wrote:
Well, my point is that taking automatic rewriting as a required feature
has at least two negative impacts:
* it rules out any form of lazy update, even though for many applications
an out-of-date summary view would be acceptable for some purposes;
* requiring MVCC consistency wi
Tom Lane wrote:
I'm not sure what the most convenient user API would be for an on-demand
hard-read-only mode, but we can't use SET TRANSACTION READ ONLY for it.
It'd have to be some other syntax. Maybe just use a GUC variable
instead of bespoke syntax? SET TRANSACTION is really just syntactic
s
On Jan 17, 2008 8:22 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Andrew Dunstan wrote:
> > Tom Lane wrote:
> > > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > >
> > >> A further example shows that to_date seems to have little error checking
> > >> altogether:
> > TODO list item?
>
> We have
61 matches
Mail list logo
