On Thu, May 25, 2017 at 6:00 PM, Achilleas Mantzios <
ach...@matrix.gatewaynet.com> wrote:
> The way I do it is the following :
> - ensure a common sequence for the ID for all tables in the inheritance
> tree (usually one parent and one or more children)
> - enforce normal FK constraints for all F
The way I do it is the following :
- ensure a common sequence for the ID for all tables in the inheritance tree
(usually one parent and one or more children)
- enforce normal FK constraints for all FK relations within the same
"realm"/"tenant"/"schema" etc, i.e. where it makes sense
- for enforc
Not possible - yet.
Am 25. Mai 2017 13:48:59 MESZ schrieb Jayadevan M :
>Hi,
>
>I designed three tables so that one table inherits another, and the
>third
>table references the parent table. If a record is inserted into the
>third
>table and the value does exist in the parent table indirectly, bec
Hi,
I designed three tables so that one table inherits another, and the third
table references the parent table. If a record is inserted into the third
table and the value does exist in the parent table indirectly, because it
is present in the inherited table, I still get an error.
Is some option
On Thu, Jul 29, 2010 at 10:50:02AM +0200, Davor J. wrote:
> For completeness, I think this link
> (http://projects.nocternity.net/index.py/en/psql-inheritance) provides some
> scripts you mention.
Very interesting.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 453
"Karsten Hilbert" wrote in message
news:20100728182051.gj2...@hermes.hilbert.loc...
> On Tue, Jul 27, 2010 at 10:33:19AM +0200, Davor J. wrote:
>
>> Well... I found it out the hard way :). There are some extra caveats I
>> have
>> come along. There is the very clumsy ALTER TABLE table_name
>> I
On Tue, Jul 27, 2010 at 10:33:19AM +0200, Davor J. wrote:
> Well... I found it out the hard way :). There are some extra caveats I have
> come along. There is the very clumsy ALTER TABLE table_name
> INHERIT(parent_table) which simply presupposes the parent's columns, but
> doesn't enforce it t
On Tue, Jul 27, 2010 at 10:36:16AM +0200, Davor J. wrote:
> For me Vick's question just proves that inheritance in relational databases
> is a complex issue. It shows that trigger propagation is not always desired,
Now that's for sure :-)
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167
"Craig Ringer" wrote in message
news:4c3ed37c.1070...@postnewspapers.com.au...
> My understanding is that it's mostly an implementation limitation. In
> other words, rather than any fundamental reason why it should not be
> done, the issue is that nobody has gone and implemented it, tested it,
>
""Karsten Hilbert"" wrote in message
news:20100719182027.123...@gmx.net...
>> On Thu, Jul 15, 2010 at 4:05 AM, Davor J. wrote:
>> > It seems no secret that a child table will not fire a trigger defined
>> > on
>> > it's parent table. Various posts comment on this. But nowhere could I
>> find a
> On Thu, Jul 15, 2010 at 4:05 AM, Davor J. wrote:
> > It seems no secret that a child table will not fire a trigger defined on
> > it's parent table. Various posts comment on this. But nowhere could I
> find a
> > reason for this.
>
> Do you want your trigger that redirects insert on parent tabl
On Thu, Jul 15, 2010 at 4:05 AM, Davor J. wrote:
> It seems no secret that a child table will not fire a trigger defined on
> it's parent table. Various posts comment on this. But nowhere could I find a
> reason for this.
Do you want your trigger that redirects insert on parent table to the
prope
Hi all.
I'd like to know how efficient is inheritance when the number of
children gets higher and higher.
I mean both with and without the constraint exclusion.
Will this change with 9.0 or possibly 9.1?
Thanks.
--
Vincenzo Romano
NotOrAnd Information Technologies
NON QVIETIS MARIBVS NAVTA PERI
On 15/07/10 16:05, Davor J. wrote:
> It seems no secret that a child table will not fire a trigger defined on
> it's parent table. Various posts comment on this. But nowhere could I find a
> reason for this.
[snip]
> I read in the change logs of 8.4: "Force child tables to inherit CHECK
> cons
It seems no secret that a child table will not fire a trigger defined on
it's parent table. Various posts comment on this. But nowhere could I find a
reason for this.
Now, I just wonder whether the people who request this are wrong in their
assumption that a trigger should fire on the child tab
On 1 May 2010, at 12:56, Alban Hertroys wrote:
> You could argue that some logic could be added to the handling of prepared
> statements to insert query-subplans depending on what data you use for your
> parameters, but then you're moving back in the direction of unprepared
> statements (namely
On 1 May 2010, at 5:33, John R Pierce wrote:
> Greg Smith wrote:
> my sql developer, who's been doing oracle for 15+ years, says postgres'
> partitioning is flawed from his perspective because if you have a prepared
> statement like..
>
> SELECT fields FROM partitioned_table WHERE primarykey
2010/5/1 John R Pierce :
> Greg Smith wrote:
>>
>> Enterprise grade doesn't mean anything. Partitioning designs that require
>> thousands of child tables to work right are fundamentally misdesigned
>> anyway, so there is no reason for any of the contributors to the project to
>> work on improving
Greg Smith wrote:
Enterprise grade doesn't mean anything. Partitioning designs that
require thousands of child tables to work right are fundamentally
misdesigned anyway, so there is no reason for any of the contributors
to the project to work on improving support for them. There are far
too
2010/5/1 Greg Smith :
> Vincenzo Romano wrote:
>>
>> While I can agree that "Enterprise grade" is a buzzword, it does mean
>> something: "very large amount of data" among other.
>>
>
> http://thedailywtf.com/Articles/Bitten_by_the_Enterprise_Bug.aspx
>
> It's quite straighforward to get PostgreSQL
Vincenzo Romano wrote:
While I can agree that "Enterprise grade" is a buzzword, it does mean
something: "very large amount of data" among other.
http://thedailywtf.com/Articles/Bitten_by_the_Enterprise_Bug.aspx
It's quite straighforward to get PostgreSQL up and running with many
terabytes
2010/5/1 Greg Smith :
> Vincenzo Romano wrote:
>>
>> I argued that O(n) stuff will keep it away from "enterprise grade"
>> applications.
>> I've been told earlier that "It is fine for dozens of child tables,
>> but not thousands;
>> it does need improvement."
>> This is not enterprise grade
>
> Ent
Vincenzo Romano wrote:
I argued that O(n) stuff will keep it away from "enterprise grade" applications.
I've been told earlier that "It is fine for dozens of child tables,
but not thousands;
it does need improvement."
This is not enterprise grade
Enterprise grade doesn't mean anything. Partiti
On Fri, Apr 30, 2010 at 00:19, Vincenzo Romano
wrote:
> For example, the Linux kernel made the big jump with server hardware
> thanks also to the O(1) schedulers.
Uhh linux has not had a O(1) scheduler since 2.6.23, its supposedly
O(log n) now. =)
--
Sent via pgsql-general mailing list (pgsql
Alvaro Herrera wrote:
> Vincenzo Romano wrote:
>
> > This is not enterprise grade.
>
> "Enterprise grade" is nothing but a buzzword. Oh, it's also a moving
> target. We've been not enterprise grade for years, always one feature
> behind (and strangely, the one lacking feature is always the one
Vincenzo Romano wrote:
> This is not enterprise grade.
"Enterprise grade" is nothing but a buzzword. Oh, it's also a moving
target. We've been not enterprise grade for years, always one feature
behind (and strangely, the one lacking feature is always the one of
interest to the complainant).
--
2010/4/30 Alvaro Herrera :
> Vincenzo Romano wrote:
>
>> In this specific case, if you think about "inheritance for
>> partitioning" and you stick with the example idea of "one partition
>> per month", then the current solution is more than OK.
>> In the real world, that is not really the general c
Vincenzo Romano wrote:
> In this specific case, if you think about "inheritance for
> partitioning" and you stick with the example idea of "one partition
> per month", then the current solution is more than OK.
> In the real world, that is not really the general case, especially in
> the "enterpri
On Fri, Apr 30, 2010 at 08:44:26AM +0200, Vincenzo Romano wrote:
> >>> Should I move to an "enterprise grade" version of PostgreSQL?
> >>
> >> The enterprise grade version of PostgreSQL is the community
> >> version.
> >>
> >> Proprietary forks exist, but they don't fix this kind of problem.
> >> :
2010/4/30 Vincenzo Romano :
> 2010/4/30 David Fetter :
>> On Thu, Apr 29, 2010 at 11:29:36AM +0200, Vincenzo Romano wrote:
>>> > No info about this point (partial indexes)?
>>> > Is also this geared with linear algorithms ?
>>>
>>> Should I move to an "enterprise grade" version of PostgreSQL?
>>
>>
2010/4/30 David Fetter :
> On Thu, Apr 29, 2010 at 11:29:36AM +0200, Vincenzo Romano wrote:
>> > No info about this point (partial indexes)?
>> > Is also this geared with linear algorithms ?
>>
>> Should I move to an "enterprise grade" version of PostgreSQL?
>
> The enterprise grade version of Post
On Thu, Apr 29, 2010 at 11:29:36AM +0200, Vincenzo Romano wrote:
> > No info about this point (partial indexes)?
> > Is also this geared with linear algorithms ?
>
> Should I move to an "enterprise grade" version of PostgreSQL?
The enterprise grade version of PostgreSQL is the community version.
2010/4/26 Vincenzo Romano :
> 2010/4/26 Bruce Momjian :
>> Vincenzo Romano wrote:
>>> Hi all.
>>>
>>> I'm wondering how efficient the inheritance can be.
>>> I'm using the constraint exclusion feature and for each child table
>>> (maybe but one) I have a proper CHECK constraint.
>>> How efficient c
2010/4/26 Bruce Momjian :
> Vincenzo Romano wrote:
>> Hi all.
>>
>> I'm wondering how efficient the inheritance can be.
>> I'm using the constraint exclusion feature and for each child table
>> (maybe but one) I have a proper CHECK constraint.
>> How efficient can the query planner be in choosing t
Vincenzo Romano wrote:
> Hi all.
>
> I'm wondering how efficient the inheritance can be.
> I'm using the constraint exclusion feature and for each child table
> (maybe but one) I have a proper CHECK constraint.
> How efficient can the query planner be in choosing the right child
> tables in the ca
Hi all.
I'm wondering how efficient the inheritance can be.
I'm using the constraint exclusion feature and for each child table
(maybe but one) I have a proper CHECK constraint.
How efficient can the query planner be in choosing the right child
tables in the case of, say, thousands of them?
Would
On Oct 12, 2009, at 1:21 PM, Erik Jones wrote:
On Oct 9, 2009, at 9:57 AM, Takeichi Kanzaki Cabrera wrote:
Hi everybody, I need your help. I have a hierarchy of tables, and
other table that has a foreign key with the top table of the
hierarchy, can I insert a value into the "other" table where t
On Oct 12, 2009, at 1:21 PM, Erik Jones wrote:
On Oct 9, 2009, at 9:57 AM, Takeichi Kanzaki Cabrera wrote:
Hi everybody, I need your help. I have a hierarchy of tables, and
other table that has a foreign key with the top table of the
hierarchy, can I insert a value into the "other" table where t
On Oct 9, 2009, at 9:57 AM, Takeichi Kanzaki Cabrera wrote:
Hi everybody, I need your help. I have a hierarchy of tables, and
other table that has a foreign key with the top table of the
hierarchy, can I insert a value into the "other" table where the value
it reference is not on the parent tab
Hi everybody, I need your help. I have a hierarchy of tables, and
other table that has a foreign key with the top table of the
hierarchy, can I insert a value into the "other" table where the value
it reference is not on the parent table? (it's in one of its child)
My best regards.
--
Sent via p
On Jan 16, 2009, at 9:49 AM, Glyn Astill wrote:
Hi chaps,
I've got a question about inheritance here, and I think I may have
gotten the wrong end of the stick as to how it works, or at least
when to use it.
What I intended to do was have a schema "audit" with an empty set of
tables in
Hi chaps,
I've got a question about inheritance here, and I think I may have gotten the
wrong end of the stick as to how it works, or at least when to use it.
What I intended to do was have a schema "audit" with an empty set of tables in
it, then each quarter restore our audit data into schemas
"Nathan Boley" <[EMAIL PROTECTED]> writes:
> Because people can be smarter about the data partitioning.
>
> Consider a table of users. Some are active, most are not. The active
> users account for nearly all of the users table access, but I still
> (occasionally) want to access info about the inac
Nathan Boley wrote:
Because people can be smarter about the data partitioning.
Consider a table of users. Some are active, most are not. The active
users account for nearly all of the users table access, but I still
(occasionally) want to access info about the inactive users.
Partitioning users
Because people can be smarter about the data partitioning.
Consider a table of users. Some are active, most are not. The active
users account for nearly all of the users table access, but I still
(occasionally) want to access info about the inactive users.
Partitioning users into active_users and
Gurjeet Singh wrote:
One of the advantages
of breaking up your data into partitions, as professed by Simon (I think)
(and I agree), is that you have smaller indexes, which improve performance.
And maybe having one huge index managing the uniqueness across partitioned
data just defeats the idea o
"Karsten Hilbert" <[EMAIL PROTECTED]> writes:
>> And maybe having one huge index managing the uniqueness across partitioned
>> data just defeats the idea of data partitioning!
> Except when you want uniqueness across all partitions.
Well, the point was that if the partitioning arrangement guarant
> And maybe having one huge index managing the uniqueness across partitioned
> data just defeats the idea of data partitioning!
Except when you want uniqueness across all partitions.
Karsten
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://w
On Tue, Apr 29, 2008 at 11:47 AM, Martijn van Oosterhout <[EMAIL PROTECTED]>
wrote:
> On Tue, Apr 29, 2008 at 06:31:30AM +0530, Gurjeet Singh wrote:
> > On Mon, Apr 28, 2008 at 8:01 PM, Erik Jones <[EMAIL PROTECTED]> wrote:
> > > Postgres doesn't yet handle inheritance of constraints from parent t
On Tue, Apr 29, 2008 at 06:31:30AM +0530, Gurjeet Singh wrote:
> On Mon, Apr 28, 2008 at 8:01 PM, Erik Jones <[EMAIL PROTECTED]> wrote:
> > Postgres doesn't yet handle inheritance of constraints from parent to
> > child tables via inheritance.
> Was it done by design or was it a limitation we coul
On Apr 28, 2008, at 8:01 PM, Gurjeet Singh wrote:
On Mon, Apr 28, 2008 at 8:01 PM, Erik Jones <[EMAIL PROTECTED]> wrote:
Postgres doesn't yet handle inheritance of constraints from parent
to child tables via inheritance.
Was it done by design or was it a limitation we couldn't get over?
On Mon, Apr 28, 2008 at 8:01 PM, Erik Jones <[EMAIL PROTECTED]> wrote:
>
> Postgres doesn't yet handle inheritance of constraints from parent to
> child tables via inheritance.
>
>
Was it done by design or was it a limitation we couldn't get over?
Best regards,
--
[EMAIL PROTECTED]
[EMAIL PROTEC
On Apr 27, 2008, at 8:23 PM, Tom Allison wrote:
create table master (
id serial,
mdn varchar(11),
meid varchar(18),
min varchar(11),
constraint mmm_master unique (mdn, meid, min)
);
insert into master(mdn, meid, min)
select mdn, meid, min from test_data where meid !=
'00' limi
Tom Allison wrote:
Am I missing something in the fine print?
fine print = see 5.8.1 Caveats on
http://www.postgresql.org/docs/8.3/interactive/ddl-inherit.html
klint.
--
Klint Gore
Database Manager
Sheep CRC
A.G.B.U.
University of New England
Armidale NSW 2350
Ph: 02 6773 3789
Fax: 02 6773
create table master (
id serial,
mdn varchar(11),
meid varchar(18),
min varchar(11),
constraint mmm_master unique (mdn, meid, min)
);
insert into master(mdn, meid, min)
select mdn, meid, min from test_data where meid != '00'
limit 10;
Everything works up to this point...
insert
Ran into something really unexpected, but then I've never tried using
inherited tables.
I have a master table (named master) that has two child tables.
create table master (
id serial,
foo varchar(20),
bar varchar(20),
constraint foobar_master unique (foo,bar)
);
Now when I do this wit
Great, super thanks!
Sebastjan
On 10/29/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> I wrote:
> > "Sebastjan Trepca" <[EMAIL PROTECTED]> writes:
> >> This is how to reproduce this issue:
> >> ...
> >> inh_test=# alter table capitals inherit cities;
>
> > Fascinating. pg_dump is almost smart enough
I wrote:
> "Sebastjan Trepca" <[EMAIL PROTECTED]> writes:
>> This is how to reproduce this issue:
>> ...
>> inh_test=# alter table capitals inherit cities;
> Fascinating. pg_dump is almost smart enough to get this right, ...
I've fixed this --- if you need a patch right away, see here:
http://ar
"Sebastjan Trepca" <[EMAIL PROTECTED]> writes:
> This is how to reproduce this issue:
> ...
> inh_test=# alter table capitals inherit cities;
Fascinating. pg_dump is almost smart enough to get this right, except
that what it spits out is
ALTER TABLE capitals ALTER COLUMN id SET DEFAULT
nextval(
Hi,
sorry for late response and lack of details. Postgresql version is 8.2.5 .
This is how to reproduce this issue:
inh_test=# CREATE TABLE cities (
inh_test(# id serial,
inh_test(# nametext,
inh_test(# population float,
inh_test(# altitudeint -- in f
PostgreSQL foreign keys won't enforce restrictions the way you want them to;
you'll have to use a trigger. And at that point, you might as well consider
alternative designs...
--
Scott Ribe
[EMAIL PROTECTED]
http://www.killerbytes.com/
(303) 722-0567 voice
---(end of br
On 10/20/07, M. van Egmond <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Im trying to use table inheritance in my database. I need it because i want
> to be able to link any object in the database to another. So i created a
> table my_object which has a serial, nothing more. All the other tables in
> th
Hi all,
Im trying to use table inheritance in my database. I need it because i want
to be able to link any object in the database to another. So i created a
table my_object which has a serial, nothing more. All the other tables in
the system are inherited from this my_object table. Im having diffi
Webb Sprague escribió:
> > > Is it
> > > possible to have FK that spans into child tables?
> >
> > This is a well known (and documented, see [1]) deficiency. It's due to
> > the current implementation of indices, which are bound to exactly one
> > table, meaning they do return a position within
"Sebastjan Trepca" <[EMAIL PROTECTED]> writes:
> Current state:
> Table B has a primary key with sequence b_seq. Table A also has a
> primary key with sequence a_seq.
In view of the fact that primary keys aren't inherited, and do not
"have sequences", this description is uselessly imprecise. Ple
Hi,
I noticed a small bug/problem when restoring a database that uses inheritance.
Lets say you have a table B that inherits from table A.
Current state:
Table B has a primary key with sequence b_seq. Table A also has a
primary key with sequence a_seq.
Now we create a backup and restore the da
> Is this set to be fixed in any particular release?
Depending on what you're doing, this may be overkill, but: I have child
tables that not only need FK constraints, but also triggers and the
functions called by the triggers. So instead of writing this over and over
again, I eventually wrote a si
> > Is it
> > possible to have FK that spans into child tables?
>
> This is a well known (and documented, see [1]) deficiency. It's due to
> the current implementation of indices, which are bound to exactly one
> table, meaning they do return a position within the table, but cannot
> point to di
On Thu, 2007-06-07 at 09:44 +0100, Richard Huxton wrote:
> Sebastjan Trepca wrote:
> > Hi,
> >
> > as I understood, when you create a table which inherits some other
> > table, the constraints and indexes do not go to the child table hence
> > you have to create a separate ones in there. That mean
Sebastjan Trepca wrote:
Hi,
as I understood, when you create a table which inherits some other
table, the constraints and indexes do not go to the child table hence
you have to create a separate ones in there. That means you cannot
depend that you won't have duplicate IDs in both tables. Right?
Hi,
as I understood, when you create a table which inherits some other
table, the constraints and indexes do not go to the child table hence
you have to create a separate ones in there. That means you cannot
depend that you won't have duplicate IDs in both tables. Right?
BUT...what if child tabl
On Thu, May 24, 2007 at 04:44:53PM -0700, Raymond C. Rodgers wrote:
> The question, and point, is this: Is there an alternate way of
> accomplishing read and write functionality similar to what inheritance
> offers but allowing me to map the columns as I desire? The read only
It isn't clear fro
First, I want to confess that I am not an SQL expert or even remotely
close. :-)
Second, I believe I pretty much know the answer to my question, but I
would like to have some confirmation if you fine people don't mind.
My situation is this: I have a PHP script that some what dynamically
genera
First, I want to confess that I am not an SQL expert or even remotely
close. :-)
Second, I believe I pretty much know the answer to my question, but I
would like to have some confirmation if you fine people don't mind.
My situation is this: I have a PHP script that some what dynamically
generates
On Tue, Dec 19, 2006 at 11:20:35 +0100,
Udo Zubel <[EMAIL PROTECTED]> wrote:
> Hi Im engineering a PG database with my workmate.
> Unfortunately the inheritance feature seems not to be able to solve my
> problem.
> I have a table "order" with an orderID, each order has 1 to n types of
> article
Hi Im engineering a PG database with my workmate.
Unfortunately the inheritance feature seems not to be able to solve my problem.
I have a table "order" with an orderID, each order has 1 to n types of
articles, like services and supply articles with the same PK.
The PK is order_number and positio
06 at 09:43:35AM +0100, Karsten Hilbert wrote:
> Subject: [GENERAL] inheritance and index use (similar to UNION ALL)
> User-Agent: Mutt/1.5.13 (2006-08-11)
>
> Hi,
>
> we have a parent table root_item with a few common fields
> (one is a text field) from which a whole bunch
Hi,
we have a parent table root_item with a few common fields
(one is a text field) from which a whole bunch of child
tables derives.
We need to run queries against the text field across the
whole bunch of child tables. What naturally comes to mind is
to run the query against root_item.text_field
On Wed, 05 Jul 2006 15:51:23 +0200
"Christian Rengstl" <[EMAIL PROTECTED]> wrote:
> Hi everyone,
>
> i hope (and i'm sure) somebody can answer my question: if i have a
> master table and several "child" tables, do the child tables inherit
> the unique constraint(s) defined for the master table or
Hi everyone,
i hope (and i'm sure) somebody can answer my question: if i have a master table
and several "child" tables, do the child tables inherit the unique
constraint(s) defined for the master table or do i have to define the same
constraints for the same fields in all the child tables?
Th
ok i have understand
many thanks to all!
On 6/27/06, Erik Jones <[EMAIL PROTECTED]> wrote:
nik600 wrote:
> hi
>
> i don't have understand how works inheritance of tables...
>
> if table B inherits from table A
>
> - A and B must share primary keys?
>
> - if i isert record in B the record is rep
Inheritance in postgre means you will have same fields definition
like the inherited table plus its own fields. So if table B is inherit
table A,
table B will have same field definition like A plus table B own
unique field(s).
It wont share primary keys, table B just have primary key in th
nik600 wrote:
hi
i don't have understand how works inheritance of tables...
if table B inherits from table A
- A and B must share primary keys?
- if i isert record in B the record is replaced in A ?
can i avoid this?
i would like to have this scenario:
table A
table B inheridts from A
tab
> i don't have understand how works inheritance of tables...
> if table B inherits from table A
> - A and B must share primary keys?
No, currently there is no unique constraint that will force uniqueness across
parent/child/sibling
tables. Just think of them as being nothing more than seperate
hi
i don't have understand how works inheritance of tables...
if table B inherits from table A
- A and B must share primary keys?
- if i isert record in B the record is replaced in A ?
can i avoid this?
i would like to have this scenario:
table A
table B inheridts from A
table C inheridts
Richard Broersma Jr scrisse in data 03/28/06 15:18:
No it isn't. But I remember reading on one of the lists that it was on the to-do list for 8.2.
However, I do not know how high it is on the list of things to do. So I imagine that there is the
potential that it might not be added.
I'll wai
> Jebus scrisse in data 03/27/06 19:03:
>
> >I could be wrong but primary keys and other constraints are not inherited.
do you know if
> this problem is solved in postgres 8.1?
No it isn't. But I remember reading on one of the lists that it was on the
to-do list for 8.2.
However, I do not kno
Jebus scrisse in data 03/27/06 19:03:
I could be wrong but primary keys and other constraints are not inherited.
Thank you very much Jebus; in effect I've found in the mailing list
archives a 2003 thread "INHERITS and Foreign keys" that claim the same
problem. Someone (Stephan Szabo) answer
Hi, I'm new on postgres and I've just installed postgres 7.4.7 on a
debian sarge. I'm interested on using inheritance. I've tried a simple code:
CREATE TABLE t_main (
id serial primary key
);
CREATE TABLE t_derived1 (
field1 varchar(128)default NULL
) IN
On 12/23/05, Karsten Hilbert <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 22, 2005 at 05:05:49PM -0700, Trent Shipley wrote:
>
> > On Wednesday 2005-12-21 07:50, Karsten Hilbert wrote:
>
> > > I would assume quite a few people would use table
> > > inheritance in a simple way were it available in a mor
On Thu, Dec 22, 2005 at 05:05:49PM -0700, Trent Shipley wrote:
> On Wednesday 2005-12-21 07:50, Karsten Hilbert wrote:
> > I would assume quite a few people would use table
> > inheritance in a simple way were it available in a more
> > convenient fashion: to transport fields, primary and foreign
On Wednesday 2005-12-21 07:50, Karsten Hilbert wrote:
> On Wed, Dec 21, 2005 at 01:52:34PM +0100, Martijn van Oosterhout wrote:
> > On Sun, Dec 04, 2005 at 10:59:10PM -0700, Trent Shipley wrote:
> > > Relational Constraint Inheritance Algebra
> > > With regard to class and attribute uniqueness
> >
On Wed, Dec 21, 2005 at 01:52:34PM +0100, Martijn van Oosterhout wrote:
> On Sun, Dec 04, 2005 at 10:59:10PM -0700, Trent Shipley wrote:
> > Relational Constraint Inheritance Algebra
> > With regard to class and attribute uniqueness
>
> It's taken a while to digest this and sorry for the delay. Wh
On Sun, Dec 04, 2005 at 10:59:10PM -0700, Trent Shipley wrote:
> Relational Constraint Inheritance Algebra
> With regard to class and attribute uniqueness
It's taken a while to digest this and sorry for the delay. While I find
the ideas intreguing there is a little voice in the back of my head
a
i have a project where inheritance could be used, i think. but after
going through the lists and having read the FM's, i realize that i beter
use another approach. i just describe the project in short :
users have to fill in forms, that mainly exists of different lists
and/or textboxes. Users
Trent,
although I cannot contribute much of anything to your line
of thought I'd encourage you to keep on with it as it'd be
highly desirable (for GNUmed at least) to have a stronger/
more encompassing inheritance solution in PostgreSQL.
Karsten,
GNUmed developer
--
GPG key ID E4071346 @ wwwkeys
[
This post is theory oriented, so it can't go in HACKERS
nor can it go in SQL
so it gets posted to GENERAL.
I would polish this more. Unfortunately, it is at the point were I'd seek
feedback were I in a seminar.
]
Relational Constraint Inheritance Algebra
With regard to class and attribute u
William Bug wrote:
>
>
> I'm not certain I understand what you mean here? Are you recommending
> all application layer interaction with tables using INHERIT should be
> done via a VIEW intermediary? If so, wouldn't the VIEW (built from a
> "SELECT ... ONLY...") then be as dependent on the f
Once again, many many thanks Jeff for taking the time to think
through these issues and provide your well-informed comments & opinions!
On Aug 10, 2005, at 4:09 PM, Jeff Davis wrote:
William Bug wrote:
As you say, both LIKE & INHERIT are a bit anemic and unnecessary,
since
what they provi
William Bug wrote:
> As you say, both LIKE & INHERIT are a bit anemic and unnecessary, since
> what they provide can be implemented via VIEWs and RULEs/ TRIGGERs. I'd
I'd like to point out that INHERITS is unique, although I'm not sure all
of the exact differences. The main difference that I see
1 - 100 of 152 matches
Mail list logo
