Jim C. Nasby [EMAIL PROTECTED] writes:
On Fri, Jul 20, 2007 at 12:40:46PM +0100, Gregory Stark wrote:
One of the main use cases I envision is wanting to create new partitions
suitable for being added to a partitioned table.
Except that's normally done with CREATE TABLE INHERITS, which
Tatsuo Ishii [EMAIL PROTECTED] writes:
Can someone enligten me what the usecase for CREATE TABLE LIKE at this
moment is?
One of the main use cases I envision is wanting to create new partitions
suitable for being added to a partitioned table.
--
Gregory Stark
EnterpriseDB
Can someone enligten me what the usecase for CREATE TABLE LIKE at this
moment is?
I read the doc and followed the discssion in this thread in
pgsql-patches list but it was hard for me to figure out.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
I've applied the latest version of the patch to HEAD. Thanks
On Tue, 2007-10-07 at 12:53 +0530, NikhilS wrote:
Yes, in the CREATE..LIKE case, options will be NULL and in the normal
CREATE..INDEX case inhreloptions will be NULL. Note that options is a
List of DefElem entries, whereas inhreloptions is a char pointer.
Hmm, right -- ugly. I'll just stick
Hi,
Attached is a revised patch that does that. Barring any objections, I'll
apply this to HEAD tomorrow.
A minor correction below in your patch:
--- src/include/commands/defrem.h 16 Jul 2007 05:19:43 -
*** extern void DefineIndex(RangeVar *heapRe
*** 26,31
---
On Mon, 2007-16-07 at 14:28 +0530, NikhilS wrote:
Guess you want to use src_options here to be uniform with usages
elsewhere that you have replaced.
Thanks, good catch.
You suppose src_options is much more readable than inhreloptions
or inh_idxoptions? Your call :).
Yeah, I'm not
Hi,
You suppose src_options is much more readable than inhreloptions
or inh_idxoptions? Your call :).
Yeah, I'm not necessarily sure that it is. inhreloptions made me think
of table inheritance, whereas LIKE in general is more of a source =
target copying operation. But I'm not convinced
I've applied the latest version of the patch to HEAD. Thanks for the
patches, Nikhil and Trevor -- we can take a look at improving INCLUDING
CONSTRAINTS for 8.4.
On Mon, 2007-16-07 at 15:50 +0530, NikhilS wrote:
I agree, since its a LIKE operation and not inheritance as such, how about
Hi,
This version updates the patch to CVS HEAD and has various fixes and
refactoring, including proper docs. I refactored get_opclass_name() into
lsyscache.c, but then realized that this means that lsyscache.c will
depend on commands/indexcmds.c (for GetDefaultOpClass()), which is
arguably
Neil Conway wrote:
On Tue, 2007-05-06 at 14:50 +0530, NikhilS wrote:
PFA, a patch which provides the CREATE .. INCLUDING INDEXES
functionality. This patch uses the same functionality introduced by
the earlier patches in this thread albeit for the INCLUDING INDEXES
case.
Attached is a
On 7/10/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Neil Conway wrote:
Attached is a revised version of this patch. Sorry for taking so long to
make progress on this: my new job been keeping my busy, and I've
recently been ill.
Illness only counts as an excuse if you _don't_ recover. If you
On Tue, 2007-05-06 at 14:50 +0530, NikhilS wrote:
PFA, a patch which provides the CREATE .. INCLUDING INDEXES
functionality. This patch uses the same functionality introduced by
the earlier patches in this thread albeit for the INCLUDING INDEXES
case.
Attached is a revised version of this
Hi,
Anyways, this patch and the functionality introduced herein will be useful
in the CREATE .. INCLUDING INDEXES case too.
No doubt. But those are different features and we shouldn't confuse
'em; in particular not put behavior into the INCLUDING CONSTRAINTS case
that shouldn't be there.
Hi,
On 6/3/07, Neil Conway [EMAIL PROTECTED] wrote:
On Mon, 2007-21-05 at 12:23 +0530, NikhilS wrote:
I had spent some time on this earlier so decided to complete and send
the patch to you for review. This patch supports copying of
expressions, predicates, opclass, amorder, reloptions etc.
Hi,
On 6/3/07, Tom Lane [EMAIL PROTECTED] wrote:
Neil Conway [EMAIL PROTECTED] writes:
Attached is a revised version of this patch.
This still seems to fundamentally misunderstand the difference between
an index and a constraint. IMHO it should not be examining pg_index
(or specifically,
NikhilS [EMAIL PROTECTED] writes:
On 6/3/07, Tom Lane [EMAIL PROTECTED] wrote:
This still seems to fundamentally misunderstand the difference between
an index and a constraint. IMHO it should not be examining pg_index
(or specifically, the index Relations) at all.
Anyways, this patch and
On Mon, 2007-21-05 at 12:23 +0530, NikhilS wrote:
I had spent some time on this earlier so decided to complete and send
the patch to you for review. This patch supports copying of
expressions, predicates, opclass, amorder, reloptions etc. The test
case also contains some more additions with
Neil Conway [EMAIL PROTECTED] writes:
Attached is a revised version of this patch.
This still seems to fundamentally misunderstand the difference between
an index and a constraint. IMHO it should not be examining pg_index
(or specifically, the index Relations) at all.
Bruce Momjian [EMAIL PROTECTED] writes:
OK, so the patch is ready to be applied?
Neil's still reviewing it, last I heard.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Hi,
The index creation happens after the new table (which is LIKE the parent)
has been created, by appending the cxt.alist information to
extras_after. The entry point for the index creation is thus via
ProcessUtility which expects an IndexStmt structure. That is why the current
patch does all
Hi,
On 5/23/07, NikhilS [EMAIL PROTECTED] wrote:
Hi,
The index creation happens after the new table (which is LIKE the
parent) has been created, by appending the cxt.alist information to
extras_after. The entry point for the index creation is thus via
ProcessUtility which expects an
NikhilS escribió:
Sorry for the barrage of emails. But as I looked closely at the current
patch there are only 2 fields (accessMethod and tableSpace) in IndexStmt
structure that we populate by doing the conversion from OIDs to name. For
the other fields, the current transformations will
NikhilS [EMAIL PROTECTED] writes:
If so, I think we can introduce 2 Oid fields in the IndexStmt structure and
store the Oids there. In DefineIndex we can use these Oids if they are not
invalid.
I think this is just make-work that causes the patch to complicate parts
of the system it didn't
Hi,
On 5/23/07, Tom Lane [EMAIL PROTECTED] wrote:
NikhilS [EMAIL PROTECTED] writes:
If so, I think we can introduce 2 Oid fields in the IndexStmt structure
and
store the Oids there. In DefineIndex we can use these Oids if they are
not
invalid.
I think this is just make-work that causes the
NikhilS escribió:
On 5/23/07, Tom Lane [EMAIL PROTECTED] wrote:
NikhilS [EMAIL PROTECTED] writes:
If so, I think we can introduce 2 Oid fields in the IndexStmt
structure and store the Oids there. In DefineIndex we can use these
Oids if they are not invalid.
I think this is just
Alvaro Herrera [EMAIL PROTECTED] writes:
Not sure. Is it possible that the schema is renamed while the operation
is being executed? If it's not then this not a problem at all so the
existing patch is fine.
There are hazards of that type in CREATE TABLE right now; it's hardly
fair to hold
Hi,
I agree this will unnecessary add arguments to the DefineIndex API. If we
stick to the patch's earlier way of converting the Oid to names for just
these 2 arguments, we can avoid this IMO.
Considering that we will be generating this information from existing
valid
index information, I
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Bruce Momjian escribió:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
I noticed that this patch uses names for some
Hi Neil,
On 5/18/07, Neil Conway [EMAIL PROTECTED] wrote:
On Mon, 2007-14-05 at 22:58 -0400, Neil Conway wrote:
Has a revised version of this patch been submitted?
In the absence of a revised patch, I can finish the feature myself, but
I won't get the free cycles until after PGCon. I can
Hi,
Since this patch is going to consider creating unique/primary indexes
assuming them to be constraints,
If it does that it will be rejected. There is a difference here and
that difference has to be maintained.
The correct way to think about this is that a pg_constraint entry of
type
Hi,
[ remembering previous discussions more clearly... ] Actually there
is a concrete problem here: unique constraints are supposed to be
represented in the information_schema views, and there is no
spec-compliant way to do that for a constraint on something other than
a column. We'd have to
NikhilS [EMAIL PROTECTED] writes:
[ remembering previous discussions more clearly... ] Actually there
is a concrete problem here: unique constraints are supposed to be
represented in the information_schema views, and there is no
spec-compliant way to do that for a constraint on something
Hi,
Nope:
neilc=# create table t1 (a int, b int);
CREATE TABLE
neilc=# create unique index t1_a_idx on t1 ((a + b)) where (a 5);
CREATE INDEX
I just now realized that even though we allow the above. We do not allow:
pg=# create table t1 (a int, b int, unique(a+b));
nor the where clause
NikhilS [EMAIL PROTECTED] writes:
I just now realized that even though we allow the above. We do not allow:
pg=# create table t1 (a int, b int, unique(a+b));
Any specific reason for this behaviour?
It'd be contrary to SQL spec. The UNIQUE constraint takes a list of
column names, full stop.
Tom Lane [EMAIL PROTECTED] writes:
NikhilS [EMAIL PROTECTED] writes:
I just now realized that even though we allow the above. We do not allow:
pg=# create table t1 (a int, b int, unique(a+b));
Any specific reason for this behaviour?
It'd be contrary to SQL spec. The UNIQUE constraint
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
It'd be contrary to SQL spec. The UNIQUE constraint takes a list of
column names, full stop.
Does the SQL spec actually specify what happens if you provide an
non-compliant table definition like this?
It does not.
I wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Does the SQL spec actually specify what happens if you provide an
non-compliant table definition like this?
It does not. We could accept expressions there, and pray that the SQL
committee never extends the spec syntax in a direction
Neil Conway wrote:
On Mon, 2007-14-05 at 22:58 -0400, Neil Conway wrote:
Has a revised version of this patch been submitted?
In the absence of a revised patch, I can finish the feature myself, but
I won't get the free cycles until after PGCon. I can commit to getting
it done before the end
On Fri, 2007-27-04 at 18:59 -0400, Neil Conway wrote:
This patch needs more work.
Has a revised version of this patch been submitted?
-Neil
---(end of broadcast)---
TIP 6: explain analyze is your friend
Hi,
On 5/3/07, Tom Lane [EMAIL PROTECTED] wrote:
NikhilS [EMAIL PROTECTED] writes:
Hi Neil,
* the patch is broken for expressional indexes, and silently omits
copying the predicate that may be associated with an index.
Since this patch is only supposed to copy unique/primary indexes, I
NikhilS [EMAIL PROTECTED] writes:
But this patch is not for the INCLUDING INDEXES case.
Pardon me for being misled by the thread title :-(
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive
Hi Neil,
* the patch is broken for expressional indexes, and silently omits
copying the predicate that may be associated with an index. It also
doesn't copy the index's amoptions (WITH clause), or the NULLS
FIRST/etc. options that may be associated with any of the index's
columns.
Since
NikhilS [EMAIL PROTECTED] writes:
Hi Neil,
* the patch is broken for expressional indexes, and silently omits
copying the predicate that may be associated with an index.
Since this patch is only supposed to copy unique/primary indexes, I dont
think we will ever have predicates associated to
On Wed, 2007-02-05 at 17:09 +0530, NikhilS wrote:
Since this patch is only supposed to copy unique/primary indexes, I
dont think we will ever have predicates associated to such indexes?
Nope:
neilc=# create table t1 (a int, b int);
CREATE TABLE
neilc=# create unique index t1_a_idx on t1 ((a +
This patch needs more work. How carefully did you test it?
* the patch failed to copy index constraints if there was not also at
least one CHECK constraint defined on the table
* the patch is broken for expressional indexes, and silently omits
copying the predicate that may be associated with an
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
NikhilS wrote:
Hi Trevor,
+
+ parent_index_info =
BuildIndexInfo(parent_index);
The above is not used anywhere else in the code and seems redundant.
Yep, pulled that out.
+
+ ereport(NOTICE,
Bruce Momjian wrote:
NikhilS wrote:
Hi,
On 4/10/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Added to TODO:
o Have WITH CONSTRAINTS also create constraint indexes
http://archives.postgresql.org/pgsql-patches/2007-04/msg00149.php
Trevor's patch does add unique/primary
Hi Trevor,
+
+ parent_index_info =
BuildIndexInfo(parent_index);
The above is not used anywhere else in the code and seems redundant.
+
+ ereport(NOTICE,
+
NikhilS wrote:
Hi,
On 4/10/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Added to TODO:
o Have WITH CONSTRAINTS also create constraint indexes
http://archives.postgresql.org/pgsql-patches/2007-04/msg00149.php
Trevor's patch does add unique/primary indexes. This would
Hi,
On 4/10/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Added to TODO:
o Have WITH CONSTRAINTS also create constraint indexes
http://archives.postgresql.org/pgsql-patches/2007-04/msg00149.php
Trevor's patch does add unique/primary indexes. This would mean that we have
to remove
Added to TODO:
o Have WITH CONSTRAINTS also create constraint indexes
http://archives.postgresql.org/pgsql-patches/2007-04/msg00149.php
---
Trevor Hardcastle wrote:
Greetings all,
I wrote this patch
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Uh, shouldn't CREATE TABLE LIKE INCLUDING CONSTRAINTS already be including
any indexes in the parent table?
You could argue it should for unique indexes since our unique indexes are how
we implement unique constraints. But I
Uh, shouldn't CREATE TABLE LIKE INCLUDING CONSTRAINTS already be including
any indexes in the parent table?
---
Trevor Hardcastle wrote:
Greetings all,
I wrote this patch about a week ago to introduce myself to coding
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
56 matches
Mail list logo
