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 something on hold for
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
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
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
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 news server to
* 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 ... no patches
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
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
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
-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 different
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
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 be a problem.
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 performance regression in
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 too.
Please
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
-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
-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 were
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
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.
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
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.
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 thought that stood
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 different
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). But
-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 really
-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 as a
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 (for me).
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
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
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?
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
worlds.
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
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
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]
!
-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
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, the
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 about
-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 lets do
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 100mil
-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]
[EMAIL
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
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 what
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
-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 could be
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, has
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.
You
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 direct manual
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, as I
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 it into 8.3RC1. Will it
-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 not really
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 storage
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 doing
this
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.
--
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 mention:
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?
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 go away
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 immediate benefit is
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 that
-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 per-table
-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 appropriate
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.
61 matches
Mail list logo
