Is there enough for a TODO here?
On Mon, Oct 03, 2005 at 11:24:30PM -0400, Greg Stark wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
On P, 2005-10-02 at 23:00 -0400, Tom Lane wrote:
Here's another interesting case to think about:
ALTER TABLE ADD foo integer DEFAULT 1
On Sat, Oct 01, 2005 at 07:59:11PM +0100, Simon Riggs wrote:
On Sat, 2005-10-01 at 10:57 -0500, Jim C. Nasby wrote:
To clarify, this is a hard-coded implementation of what I'm asking for:
http://cvs.distributed.net/viewcvs.cgi/stats-sql/logdb/ in a nutshell:
CREATE TABLE log_other (
On P, 2005-10-02 at 22:49 -0400, Greg Stark wrote:
No, I think redefining NULL is a non-starter. This whole thing only has legs
if Postgres can distinguish between a column that has never been set and a
column that has NULL.
Actually the only case where I don't see bizarre semantic
On P, 2005-10-02 at 23:00 -0400, Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
It would be nice to be able to do:
ALTER TABLE ADD foo integer DEFAULT 1
And there's no question of what what the semantics of this are.
Sure, but you can only optimize this if the default expression
Hannu Krosing [EMAIL PROTECTED] writes:
Probably a different syntax would be better here, perhaps
ALTER TABLE ADD foo integer AS 1 WHEN MISSING;
or somesuch.
Uhm, if you're adding the column they're *all* missing. That's the whole
point. If you start inventing a new user-visible concept
Hannu Krosing [EMAIL PROTECTED] writes:
On P, 2005-10-02 at 23:00 -0400, Tom Lane wrote:
Here's another interesting case to think about:
ALTER TABLE ADD foo integer DEFAULT 1
...
ALTER TABLE ALTER foo SET DEFAULT 2
You'll have to pay the table-traversal cost on one
On Mon, 2005-10-03 at 23:24 -0400, Greg Stark wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
On P, 2005-10-02 at 23:00 -0400, Tom Lane wrote:
Here's another interesting case to think about:
ALTER TABLE ADD foo integer DEFAULT 1
...
ALTER TABLE ALTER foo SET DEFAULT 2
On Mon, 2005-10-03 at 23:51 -0400, Rod Taylor wrote:
On Mon, 2005-10-03 at 23:24 -0400, Greg Stark wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
On P, 2005-10-02 at 23:00 -0400, Tom Lane wrote:
Here's another interesting case to think about:
ALTER TABLE ADD foo
Rod Taylor [EMAIL PROTECTED] writes:
Hm. So you're saying there are only ever exactly two types of defaults. The
initial default that applies to all tuples that were created before the
column was added. And the current default that only ever applies to newly
created tuples.
That does
On Sat, Oct 01, 2005 at 04:35:49PM +0200, Martijn van Oosterhout wrote:
On Sat, Oct 01, 2005 at 10:05:22AM -0400, [EMAIL PROTECTED] wrote:
It has the 'side or additional benefit' being requested here. The ability
to filter the child table by some attribute. For example, if the child
tables
On P, 2005-10-02 at 01:24 -0400, Greg Stark wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
I also often wish that this would be possible when someone adds a column
with a default value to a multi-million row table on a 24/7 production
system and insists on filling all existing columns
On Sun, Oct 02, 2005 at 03:57:37PM +0300, Hannu Krosing wrote:
On P, 2005-10-02 at 01:24 -0400, Greg Stark wrote:
Of course that only works if the reason they want to set fill the rows with
the default value isn't precisely because NULL is a perfectly reasonable
thing
for the column to
Martijn van Oosterhout kleptog@svana.org writes:
However, from a semantic point of view, it would be a bit strange. If
you added a column, updated some rows then set a default, that default
might end up applying to every row, except the ones you already
modified. With careful coding you may
If one defines a restriction such that 'COLUMN = VALUE' for a specific
table, in a theoretical sort of model that completely ignores
implementation difficulty, or changes to the restriction, I think it
would be safe to not store COLUMN in the tuple. If the tuple is
stored, then COLUMN = VALUE, so
On Sun, Oct 02, 2005 at 11:51:27PM +0300, Hannu Krosing wrote:
Right. Actually the default value returned for missing columns should
be different from the default for new values and should be settable only
once, when adding the column, else issues would become really really
weird.
Right, the
On P, 2005-10-02 at 15:30 +0200, Martijn van Oosterhout wrote:
On Sun, Oct 02, 2005 at 03:57:37PM +0300, Hannu Krosing wrote:
On P, 2005-10-02 at 01:24 -0400, Greg Stark wrote:
Of course that only works if the reason they want to set fill the rows
with
the default value isn't
Martijn van Oosterhout kleptog@svana.org writes:
On Sun, Oct 02, 2005 at 11:51:27PM +0300, Hannu Krosing wrote:
Right. Actually the default value returned for missing columns should
be different from the default for new values and should be settable only
once, when adding the column, else
Greg Stark [EMAIL PROTECTED] writes:
It would be nice to be able to do:
ALTER TABLE ADD foo integer DEFAULT 1
And there's no question of what what the semantics of this are.
Sure, but you can only optimize this if the default expression is
immutable...
On the other hand if you do
ALTER
Tom Lane [EMAIL PROTECTED] writes:
Here's another interesting case to think about:
ALTER TABLE ADD foo integer DEFAULT 1
...
ALTER TABLE ALTER foo SET DEFAULT 2
You'll have to pay the table-traversal cost on one step or the other.
A good point.
I wonder if this could
On Wed, 2005-09-28 at 22:24 +0200, Martijn van Oosterhout wrote:
On Wed, Sep 28, 2005 at 11:00:46PM +0400, Ilia Kantor wrote:
Your suggestion is essentially the same as mine..
There exists tableoid, pretty much suited to tell between tables in the case
of inheritance.. I can't see a real
On Fri, 2005-09-30 at 18:30 -0500, Jim C. Nasby wrote:
I thought char was actually stored variable-length...? I know there's a
type that actually acts like char does on most databases, but I can't
remember what it is off-hand (it should be mentioned in docs 8.3...)
You are correct on that
On Fri, Sep 30, 2005 at 06:30:10PM -0500, Jim C. Nasby wrote:
On Wed, Sep 28, 2005 at 07:25:46PM +0100, Simon Riggs wrote:
Include the Discriminator as a column in A and it will be inherited by
all A1, A2, A3.
e.g. concrete_class char(1) not null
snip
This will add 1 byte per row in
On Fri, Sep 30, 2005 at 09:54:39PM +0100, Simon Riggs wrote:
On Wed, 2005-09-28 at 22:24 +0200, Martijn van Oosterhout wrote:
I wonder if it would be possible to tweak the constraints exclusion
code so that if it sees something of the form tableoid = X to exclude
other tables...
You know,
On Sat, Oct 01, 2005 at 10:05:22AM -0400, [EMAIL PROTECTED] wrote:
It has the 'side or additional benefit' being requested here. The ability
to filter the child table by some attribute. For example, if the child
tables are used for partitioning, and the attribute were to keep a date
range, the
To clarify, this is a hard-coded implementation of what I'm asking for:
http://cvs.distributed.net/viewcvs.cgi/stats-sql/logdb/ in a nutshell:
CREATE TABLE log_other (
project_id smallint NOT NULL
...
)
CREATE TABLE log_8 (
-- No project_id
...
)
CREATE TABLE log_24, log_25,
On Sat, Oct 01, 2005 at 09:43:03AM +0100, Simon Riggs wrote:
On Fri, 2005-09-30 at 18:30 -0500, Jim C. Nasby wrote:
I thought char was actually stored variable-length...? I know there's a
type that actually acts like char does on most databases, but I can't
remember what it is off-hand
On Sat, Oct 01, 2005 at 02:13:09PM +0200, Martijn van Oosterhout wrote:
On Fri, Sep 30, 2005 at 06:30:10PM -0500, Jim C. Nasby wrote:
On Wed, Sep 28, 2005 at 07:25:46PM +0100, Simon Riggs wrote:
Include the Discriminator as a column in A and it will be inherited by
all A1, A2, A3.
Jim C. Nasby wrote:
On Sat, Oct 01, 2005 at 02:13:09PM +0200, Martijn van Oosterhout wrote:
On Fri, Sep 30, 2005 at 06:30:10PM -0500, Jim C. Nasby wrote:
On Wed, Sep 28, 2005 at 07:25:46PM +0100, Simon Riggs wrote:
Include the Discriminator as a column in A and it will be
Hmm, I'm trying to understand here. If every row in log_8 should have
the same project_id, couldn't this be acheived by having each row in log_other
contain the tableoid of the table it refers to. Then a join will return
the info you're looking for.
Or am I missing something?
On Sat, Oct 01,
On Sat, Oct 01, 2005 at 06:28:03PM +0200, Martijn van Oosterhout wrote:
Hmm, I'm trying to understand here. If every row in log_8 should have
the same project_id, couldn't this be acheived by having each row in log_other
contain the tableoid of the table it refers to. Then a join will return
On Sat, 2005-10-01 at 10:57 -0500, Jim C. Nasby wrote:
To clarify, this is a hard-coded implementation of what I'm asking for:
http://cvs.distributed.net/viewcvs.cgi/stats-sql/logdb/ in a nutshell:
CREATE TABLE log_other (
project_id smallint NOT NULL
...
)
CREATE TABLE log_8 (
On L, 2005-10-01 at 19:59 +0100, Simon Riggs wrote:
Jim,
Your idea was noted before and actually; I mentioned it to show that I
listen and take note of ideas from any source.
For everybody, I would note that the current behaviour is exactly the
way that List Partitioning works on other
Hannu Krosing [EMAIL PROTECTED] writes:
I also often wish that this would be possible when someone adds a column
with a default value to a multi-million row table on a 24/7 production
system and insists on filling all existing columns with the default.
A rule ON SELECT FROM table_x WHERE
On Wed, Sep 28, 2005 at 10:24:18PM +0200, Martijn van Oosterhout wrote:
On Wed, Sep 28, 2005 at 11:00:46PM +0400, Ilia Kantor wrote:
Your suggestion is essentially the same as mine..
There exists tableoid, pretty much suited to tell between tables in the case
of inheritance.. I can't see a
On Wed, Sep 28, 2005 at 07:25:46PM +0100, Simon Riggs wrote:
Include the Discriminator as a column in A and it will be inherited by
all A1, A2, A3.
e.g. concrete_class char(1) not null
snip
This will add 1 byte per row in your superclass... and requires no
I thought char was actually
Ilia,
Well, Simon is still writing the CE docs. In the meantime:
http://archives.postgresql.org/pgsql-hackers/2005-07/msg00461.php
--josh
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose
Maybe new constraint_exclusion staff could help to exclude non-matching
tables from inheritance query ?
Yes, that's exactly what it's for. Your testing is welcome. Download 8.1
and try it today.
Great, I'm developing on 8.1b2 now...
But could you be more particular about the solution ?
Let table A be inherited by A1, A2, A3.
How to select from A records where actual relations are A1, A2 ?
Why not just select directly from the child tables? I can't get excited
about optimizing the case you propose.
Because WHERE concrete_class IN (a,b,c) is much more convenient and
flexible
On Tue, Sep 27, 2005 at 09:30:55PM +0400, Ilia Kantor wrote:
Let table A be inherited by A1, A2, A3.
How to select from A records where actual relations are A1, A2 ?
If A1 and A2 will be naturally together, where compared to A, or A3,
why not introduce an intermediate table?
A would be
On Wed, 2005-09-28 at 12:13 +0400, Ilia Kantor wrote:
Let table A be inherited by A1, A2, A3.
How to select from A records where actual relations are A1, A2 ?
Why not just select directly from the child tables? I can't get excited
about optimizing the case you propose.
Because WHERE
If you treat the sub-class Discriminator as a data item rather than some
additional syntax for class membership then you will find this works
very straightforwardly for you.
Your suggestion is essentially the same as mine..
There exists tableoid, pretty much suited to tell between tables in
On Wed, Sep 28, 2005 at 11:00:46PM +0400, Ilia Kantor wrote:
Your suggestion is essentially the same as mine..
There exists tableoid, pretty much suited to tell between tables in the case
of inheritance.. I can't see a real need to add a special class
classifier to each table..
This solution
Let table A be inherited by A1, A2, A3.
How to select from A records where actual relations
are A1, A2 ?
I found a way somewhere, it sounds like SELECT
WHERE tableoid IN (a1.oid, a2.oid),
but tableoid checks actually do seq scan.
Like: SELECT * FROM sometable WHERE tableoid
Ilia,
Maybe new constraint_exclusion staff could help to exclude non-matching
tables from inheritance query ?
Yes, that's exactly what it's for. Your testing is welcome. Download 8.1
and try it today.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
Ilia Kantor [EMAIL PROTECTED] writes:
Let table A be inherited by A1, A2, A3.
How to select from A records where actual relations are A1, A2 ?
Why not just select directly from the child tables? I can't get excited
about optimizing the case you propose.
regards, tom
45 matches
Mail list logo
