Tom Lane wrote:
BTW, aside from selecting the index the command would have to verify
that the indexed columns are all NOT NULL. We could either have it
just throw an error if they aren't, or have it silently try to do
an ALTER SET NOT NULL, which would require a table scan.
I'm going to argue
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I realize most feel we don't need to add a rename to this, but there are
> two more reasons _not_ to do this.
One other thought I had about this is that the proposed syntax
ALTER TABLE tab ADD PRIMARY KEY (col [, ...]) USING INDEX foo
is not we
Joshua D. Drake wrote:
> Tom Lane wrote:
>
> >> Well it should be optional but it would be nice if we had the option to
> >> have it renamed per the default... meaning the same output if I were to
> >> do this:
> >
> > If you want that, you can rename the index (either before or afterwards).
>
On Sat, May 10, 2008 at 10:41:56PM -0400, Andrew Sullivan wrote:
> On Sat, May 10, 2008 at 11:55:29AM -0400, Tom Lane wrote:
> > IMHO a utility command should do one easily-explained thing. The
> > fewer options the better.
>
> Sticking to that principle makes for a better-maintained system. I
>
Joshua D. Drake wrote:
Tom Lane wrote:
Well it should be optional but it would be nice if we had the option
to have it renamed per the default... meaning the same output if I
were to do this:
If you want that, you can rename the index (either before or afterwards).
I don't see any reason to
On Sat, May 10, 2008 at 11:55:29AM -0400, Tom Lane wrote:
> IMHO a utility command should do one easily-explained thing. The fewer
> options the better.
Sticking to that principle makes for a better-maintained system. I
agree. If we want to point out, "You might rename your index
afterwards to
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> ALTER TABLE blah ADD ... PRIMARY KEY (...) USING PREBUILT INDEX index_hame
> If the user doesn't specify CONSTRAINT constraint_name, it will
> default to current implicit behavior of col_pkey.
IOW, the default behavior is to rename the index? Doesn
Jonah H. Harris wrote:
Yes, I just think PREBUILT conveys the meaning of the command more
appropriately. I could care less though.
(Please don't top-answer)
I don't think we should add new keywords unnecessarily.
cheers
andrew
On Sat, May 10, 2008 at 5:35 PM, Gregory Stark <[EMAIL P
Yes, I just think PREBUILT conveys the meaning of the command more
appropriately. I could care less though.
On Sat, May 10, 2008 at 5:35 PM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Jonah H. Harris" <[EMAIL PROTECTED]> writes:
>
>> So, would anyone be averse to something like the following:
>>
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> So, would anyone be averse to something like the following:
>
> ALTER TABLE blah ADD ... PRIMARY KEY (...) USING PREBUILT INDEX index_hame
>
> If the user doesn't specify CONSTRAINT constraint_name, it will
> default to current implicit behavior of c
So, would anyone be averse to something like the following:
ALTER TABLE blah ADD ... PRIMARY KEY (...) USING PREBUILT INDEX index_hame
If the user doesn't specify CONSTRAINT constraint_name, it will
default to current implicit behavior of col_pkey.
-Jonah
On Sat, May 10, 2008 at 1:08 PM, Joshu
Tom Lane wrote:
Apparently your definition of "easy" depends entirely on
keystrokes and not at all on memory/cognitive burden.
I was trying to remove one opportunity for human error, which is tied to
memory and cognitive burden. It is very easy to fat finger something. Is
it a critical error
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> As a counter point, I don't see any reason to make the DBA's life
> harder. Sure it is just one step but it is a human step, prone to error
> and taking more time than it should. Why not just make it easy?
I don't see that decorating infrequently-
Joshua D. Drake wrote:
Tom Lane wrote:
Well it should be optional but it would be nice if we had the option
to have it renamed per the default... meaning the same output if I
were to do this:
If you want that, you can rename the index (either before or
afterwards).
I don't see any reason
Tom Lane wrote:
Well it should be optional but it would be nice if we had the option to
have it renamed per the default... meaning the same output if I were to
do this:
If you want that, you can rename the index (either before or afterwards).
I don't see any reason to clutter the make-constra
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Why, and exactly what would you define as "appropriate naming style"?
>> The user has always been free to pick whatever constraint name he
>> wants.
> Well it should be optional but it would be nice if we had the option to
> have
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Bruce Momjian wrote:
Any comments, ideas, suggestions?
I would add:
5. Modify index name to use appropriate naming style.
Why, and exactly what would you define as "appropriate naming style"?
The user has always been free
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> Any comments, ideas, suggestions?
> I would add:
>5. Modify index name to use appropriate naming style.
Why, and exactly what would you define as "appropriate naming style"?
The user has always been free to pick whatever
Bruce Momjian wrote:
Added to TODO:
Proposed Implementation
1. Verify that the index named is a unique index
2. Check index columns for NOT NULL constraints
3. If indexed columns are not already NOT NULL, apply NOT NULL
4. If NOT NULL succeeds, complete the operation (catalogs,
dependencies, .
Added to TODO:
o Allow an existing index to be marked as a table's primary key
---
Jonah H. Harris wrote:
> Hey all,
>
> I've run into a couple cases now where it would be helpful to easily
> assign an already-exi
Tom Lane schrieb:
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
I've run into a couple cases now where it would be helpful to easily
assign an already-existing unique index as a primary key.
You need to present a more convincing use-case than this unsupported
assertion. There's hardly
On Tue, Apr 8, 2008 at 10:03 PM, Jonah H. Harris <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 8, 2008 at 9:04 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > "Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> > > I've run into a couple cases now where it would be helpful to easily
> > > assign an already-ex
On Tue, Apr 8, 2008 at 9:04 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> > I've run into a couple cases now where it would be helpful to easily
> > assign an already-existing unique index as a primary key.
>
> You need to present a more convincing use
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> I've run into a couple cases now where it would be helpful to easily
> assign an already-existing unique index as a primary key.
You need to present a more convincing use-case than this unsupported
assertion. There's hardly any effective difference
24 matches
Mail list logo