On Wed, Jan 26, 2011 at 6:14 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Gurjeet Singh singh.gurj...@gmail.com writes:
Attached is the updated patch with doc changes and test cases.
Applied with assorted corrections. Aside from the refactoring I wanted,
there were various oversights.
Looking
On Mon, Jan 24, 2011 at 07:01:13PM -0500, Tom Lane wrote:
One other issue that might be worthy of discussion is that as things
stand, execution of the ADD CONSTRAINT USING INDEX syntax will cause
the constraint to absorb the index as an INTERNAL dependency. That
means dropping the constraint
Sorry for not being on top of this.
On Tue, Jan 25, 2011 at 9:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
... If that's the only issue then I don't see any need to wait on
the author, so will take this one.
I find myself quite dissatisfied with the way that this patch adds yet
Gurjeet Singh singh.gurj...@gmail.com writes:
On Tue, Jan 25, 2011 at 9:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
One other issue that might be worthy of discussion is that as things
stand, execution of the ADD CONSTRAINT USING INDEX syntax will cause
the constraint to absorb the index as an
On Wed, Jan 26, 2011 at 5:31 AM, Tom Lane t...@sss.pgh.pa.us wrote:
In the end I think this is mainly an issue of setting appropriate
expectations in the documentation. I've added the following text to
the ALTER TABLE manual page:
para
After this command is executed, the index is
Gurjeet Singh singh.gurj...@gmail.com writes:
Attached is the updated patch with doc changes and test cases.
Applied with assorted corrections. Aside from the refactoring I wanted,
there were various oversights.
I have consciously disallowed the ability to specify storage_parameters
using
Steve Singer ssinger...@sympatico.ca writes:
src/backend/parser/parse_utilcmd.c: 1452
Your calling strdup on the attribute name. I don't have a good enough
grasp on the code to be able to trace this through to where the memory
gets free'd. Does it get freed? Should/could this be a call to
I wrote:
... If that's the only issue then I don't see any need to wait on
the author, so will take this one.
I find myself quite dissatisfied with the way that this patch adds yet
another bool flag to index_create (which has too many of those already),
with the effect of causing it to exactly
On Mon, Jan 24, 2011 at 7:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
One other issue that might be worthy of discussion is that as things
stand, execution of the ADD CONSTRAINT USING INDEX syntax will cause
the constraint to absorb the index as an INTERNAL dependency. That
means dropping the
I've taken a look at this version of the patch.
Submission Review
This version of the patch applies cleanly to master. It matches your git
repo and includes test + docs.
Usability Review
---
The command syntax now matches what was discussed during the last cf.
On Sun, Jan 16, 2011 at 5:34 PM, Steve Singer ssinger...@sympatico.ca wrote:
I'm marking this as returned with feedback pending your answer on the
possible memory leak above but I think the patch is very close to being
ready.
Please use Waiting on Author if the patch is to be considered
On Thu, Dec 9, 2010 at 2:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Gurjeet Singh singh.gurj...@gmail.com writes:
But I still hold a bias towards renaming the index to match constraint
name
(with a NOTICE), rather than require that the constraint name match the
index name, because the
On Sun, Dec 5, 2010 at 2:09 PM, Peter Eisentraut pete...@gmx.net wrote:
On fre, 2010-12-03 at 15:27 -0500, Robert Haas wrote:
On Fri, Dec 3, 2010 at 2:56 PM, r t pg...@xzilla.net wrote:
What exactly was the objection to the following --
ALTER TABLE table_name ADD PRIMARY KEY
Gurjeet Singh singh.gurj...@gmail.com writes:
But I still hold a bias towards renaming the index to match constraint name
(with a NOTICE), rather than require that the constraint name match the
index name, because the constraint name is optional and when it is not
provided system has to
Tom Lane t...@sss.pgh.pa.us wrote:
If the constraint name is not specified, we should certainly use
the existing index name, not randomly rename it.
+1
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Thu, Dec 9, 2010 at 2:51 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
If the constraint name is not specified, we should certainly use
the existing index name, not randomly rename it.
+1
+1
--
Robert Haas
EnterpriseDB:
On fre, 2010-12-03 at 15:27 -0500, Robert Haas wrote:
On Fri, Dec 3, 2010 at 2:56 PM, r t pg...@xzilla.net wrote:
What exactly was the objection to the following --
ALTER TABLE table_name ADD PRIMARY KEY (column_list) USING index_name;
Is the objection that you might have been trying to
On Dec 4, 2010, at 1:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Ross J. Reedstrom reeds...@rice.edu writes:
If you consider that an index basically is, in some sense, a pre-canned
column list, then:
ALTER TABLE table_name ADD PRIMARY KEY (column_list);
ALTER TABLE table_name ADD PRIMARY KEY
On Sat, Dec 4, 2010 at 6:48 AM, Robert Haas robertmh...@gmail.com wrote:
On Dec 4, 2010, at 1:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Ross J. Reedstrom reeds...@rice.edu writes:
If you consider that an index basically is, in some sense, a pre-canned
column list, then:
ALTER TABLE
Robert Treat r...@xzilla.net writes:
Actually I think I'd even be comfortable with A, either you must name the
constraint after the index, or you can leave the constraint name out, and
we'll use the index name.
Or we could omit the CONSTRAINT name clause from the syntax
altogether.
I think
On Dec 4, 2010, at 11:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Treat r...@xzilla.net writes:
Actually I think I'd even be comfortable with A, either you must name the
constraint after the index, or you can leave the constraint name out, and
we'll use the index name.
Or we could omit
On 12/04/2010 12:37 PM, Robert Haas wrote:
What would make sense to me is: create a pk constraint with the sane name as
the existing unique index. If that constraint name already exists, error.
+1, agreed. Based on this, the syntax should be obvious.
We'll need to doc what to do in the
On sön, 2010-11-28 at 20:40 -0500, Robert Haas wrote:
On Sun, Nov 28, 2010 at 8:06 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Fri, Nov 26, 2010 at 05:58, Steve Singer ssin...@ca.afilias.info wrote:
The attached version of the patch gets your regression tests to pass.
I'm
On Fri, Dec 3, 2010 at 2:23 PM, Peter Eisentraut pete...@gmx.net wrote:
On sön, 2010-11-28 at 20:40 -0500, Robert Haas wrote:
On Sun, Nov 28, 2010 at 8:06 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Fri, Nov 26, 2010 at 05:58, Steve Singer ssin...@ca.afilias.info
wrote:
The
On 03.12.2010 21:43, Robert Haas wrote:
On Fri, Dec 3, 2010 at 2:23 PM, Peter Eisentrautpete...@gmx.net wrote:
On sön, 2010-11-28 at 20:40 -0500, Robert Haas wrote:
On Sun, Nov 28, 2010 at 8:06 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Fri, Nov 26, 2010 at 05:58, Steve
Excerpts from Heikki Linnakangas's message of vie dic 03 16:45:59 -0300 2010:
ALTER TABLE table_name SET PRIMARY KEY USING INDEX index_name. Quite
verbose, but imho USING makes it much more clear that it's an existing
index.
I was going to post the same thing (well except I was still
On Fri, Dec 3, 2010 at 2:43 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Dec 3, 2010 at 2:23 PM, Peter Eisentraut pete...@gmx.net wrote:
On sön, 2010-11-28 at 20:40 -0500, Robert Haas wrote:
On Sun, Nov 28, 2010 at 8:06 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On
On 03.12.2010 21:58, Alvaro Herrera wrote:
Excerpts from Heikki Linnakangas's message of vie dic 03 16:45:59 -0300 2010:
ALTER TABLE table_name SET PRIMARY KEY USING INDEX index_name. Quite
verbose, but imho USING makes it much more clear that it's an existing
index.
I was going to post the
On Fri, Dec 3, 2010 at 2:56 PM, r t pg...@xzilla.net wrote:
What exactly was the objection to the following --
ALTER TABLE table_name ADD PRIMARY KEY (column_list) USING index_name;
Is the objection that you might have been trying to specify a constraint
named using ? I'm willing to make that
On 12/3/10 12:27 PM, Robert Haas wrote:
On Fri, Dec 3, 2010 at 2:56 PM, r t pg...@xzilla.net wrote:
What exactly was the objection to the following --
ALTER TABLE table_name ADD PRIMARY KEY (column_list) USING index_name;
Is the objection that you might have been trying to specify a constraint
On Fri, Dec 3, 2010 at 4:41 PM, Josh Berkus j...@agliodbs.com wrote:
On 12/3/10 12:27 PM, Robert Haas wrote:
On Fri, Dec 3, 2010 at 2:56 PM, r t pg...@xzilla.net wrote:
What exactly was the objection to the following --
ALTER TABLE table_name ADD PRIMARY KEY (column_list) USING index_name;
On Fri, Dec 03, 2010 at 05:16:04PM -0500, Robert Treat wrote:
On Fri, Dec 3, 2010 at 4:41 PM, Josh Berkus j...@agliodbs.com wrote:
However, I don't see why we need (column_list). Surely the index has a
column list already?
ALTER TABLE table_name ADD CONSTRAINT pk_name PRIMARY KEY USING
On 12/3/10 2:16 PM, Robert Treat wrote:
Uh, the syntax I posted was based on this currently valid syntax:
ALTER TABLE table_name ADD PRIMARY KEY (column_list);
The constraint bit is optional, which is why I left it out, but I
presume it would be optional with the new syntax as well...
Ross J. Reedstrom reeds...@rice.edu writes:
If you consider that an index basically is, in some sense, a pre-canned
column list, then:
ALTER TABLE table_name ADD PRIMARY KEY (column_list);
ALTER TABLE table_name ADD PRIMARY KEY USING index_name;
are parallel constructions. And it avoids the
On Fri, Nov 26, 2010 at 05:58, Steve Singer ssin...@ca.afilias.info wrote:
The attached version of the patch gets your regression tests to pass.
I'm going to mark this as ready for a committer.
I think we need more discussions about the syntax:
ALTER TABLE table_name ADD PRIMARY KEY (...)
On Sun, Nov 28, 2010 at 8:06 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Fri, Nov 26, 2010 at 05:58, Steve Singer ssin...@ca.afilias.info wrote:
The attached version of the patch gets your regression tests to pass.
I'm going to mark this as ready for a committer.
I think we need
On Sun, Nov 28, 2010 at 08:40:08PM -0500, Robert Haas wrote:
On Sun, Nov 28, 2010 at 8:06 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Fri, Nov 26, 2010 at 05:58, Steve Singer ssin...@ca.afilias.info wrote:
The attached version of the patch gets your regression tests to
pass.
On 10-11-22 03:24 PM, Steve Singer wrote:
On 10-11-22 09:37 AM, Gurjeet Singh wrote:
On Sat, Nov 20, 2010 at 9:00 AM, Steve Singer ssinger...@sympatico.ca
Almost fixed.
I still get an unexpected difference.
! DETAIL: cannot create PRIMARY KEY/UNIQUE constraint with a non-unique
index.
On Sat, Nov 20, 2010 at 9:00 AM, Steve Singer ssinger...@sympatico.cawrote:
Submission Review:
Tests
The expected output for the regression tests you added don't match
what I'm getting when I run the tests with your patch applied.
I think you just need
On 10-11-22 09:37 AM, Gurjeet Singh wrote:
On Sat, Nov 20, 2010 at 9:00 AM, Steve Singer ssinger...@sympatico.ca
mailto:ssinger...@sympatico.ca wrote:
Submission Review:
Tests
The expected output for the regression tests you added don't
On 10-11-07 01:54 PM, Gurjeet Singh wrote:
Attached is the patch that extends the same feature for UNIQUE indexes.
It also includes some doc changes for the ALTER TABLE command, but I
could not verify the resulting changes since I don't have the
doc-building infrastructure installed.
Regards,
Depesz brought that to my attention a few days after the initial submission,
and adding support for UNIQUE was not much pain. I implemented it almost
immediately, but didn't announce it as I was hoping I could submit some doc
changes too with that.
If you are the adventurous kind, you can follow
Attached is the patch that extends the same feature for UNIQUE indexes.
It also includes some doc changes for the ALTER TABLE command, but I could
not verify the resulting changes since I don't have the doc-building
infrastructure installed.
Regards,
On Mon, Nov 8, 2010 at 1:39 AM, Gurjeet
UNIQUE constraints suffer from the same behavior; feel like fixing that too? :)
On Oct 9, 2010, at 1:07 PM, Gurjeet Singh wrote:
This is a continuation from this thread:
http://archives.postgresql.org/pgsql-hackers/2010-09/msg02153.php
The attached patch allows creating a primary key using
On Sat, Oct 9, 2010 at 2:07 PM, Gurjeet Singh singh.gurj...@gmail.comwrote:
This is a continuation from this thread:
http://archives.postgresql.org/pgsql-hackers/2010-09/msg02153.php
The attached patch allows creating a primary key using an existing index.
I have attached two versions of
On 10/09/2010 02:19 PM, Gurjeet Singh wrote:
On Sat, Oct 9, 2010 at 2:07 PM, Gurjeet Singh singh.gurj...@gmail.com
mailto:singh.gurj...@gmail.com wrote:
This is a continuation from this thread:
http://archives.postgresql.org/pgsql-hackers/2010-09/msg02153.php
The attached patch
Andrew Dunstan and...@dunslane.net writes:
I wish we could get the archive processor to provide access to the
attachments even if they have a MIME type of text/whatever. That's a
horrid inefficiency. Maybe we could restrict it to text attachments
that have a Content-Type with a name attribute
On Sat, Oct 9, 2010 at 3:30 PM, Dimitri Fontaine dimi...@2ndquadrant.frwrote:
Andrew Dunstan and...@dunslane.net writes:
I wish we could get the archive processor to provide access to the
attachments even if they have a MIME type of text/whatever. That's a
horrid inefficiency. Maybe we
48 matches
Mail list logo
