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_othe
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 intege
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.
>
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:
> > > >
> > > >
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
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-tra
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 c
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 e
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 cons
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 thi
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
> A
Martijn van Oosterhout 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 issues wo
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
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,
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 w
Martijn van Oosterhout 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 be able to get
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 col
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 co
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
> > t
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
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 o
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
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
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, 2005
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 inh
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.
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-
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, log_
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,
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...
> >
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
>
> > This will add 1 byte per row i
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 p
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
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
> This will add 1 byte per row in your superclass... and requires no
I thought char was actually stored
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
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
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
> 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
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.
>
> Beca
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 inheri
>> 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
f
>> 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 soluti
"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,
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
44 matches
Mail list logo
