Kohei KaiGai escribió:
> 2013/2/3 Tom Lane :
> > Alvaro Herrera writes:
> >> [ pgsql-v9.3-alter-reworks.3-rename.v10.patch.gz ]
> >
> > Say ... I hadn't been paying too close attention to this patch, but
> > is there any particularly principled reason for it having unified
> > only 14 of the 29 ob
2013/2/3 Tom Lane :
> Alvaro Herrera writes:
>> [ pgsql-v9.3-alter-reworks.3-rename.v10.patch.gz ]
>
> Say ... I hadn't been paying too close attention to this patch, but
> is there any particularly principled reason for it having unified
> only 14 of the 29 object types handled by ExecRenameStmt(
Alvaro Herrera writes:
> [ pgsql-v9.3-alter-reworks.3-rename.v10.patch.gz ]
Say ... I hadn't been paying too close attention to this patch, but
is there any particularly principled reason for it having unified
only 14 of the 29 object types handled by ExecRenameStmt()?
If so, how to tell which ob
Tom Lane escribió:
> Kohei KaiGai writes:
> > About ALTER FUNCTION towards aggregate function, why we should raise
> > an error strictly?
>
> I agree we probably shouldn't --- traditionally we have allowed that,
> AFAIR, so changing it would break existing applications for little
> benefit.
Okay
Kohei KaiGai writes:
> About ALTER FUNCTION towards aggregate function, why we should raise
> an error strictly?
I agree we probably shouldn't --- traditionally we have allowed that,
AFAIR, so changing it would break existing applications for little
benefit.
Similarly, you should not be throwing
2013/1/17 Alvaro Herrera :
> Kohei KaiGai escribió:
>
>> This attached patch is the rebased one towards the latest master branch.
>
> Great, thanks. I played with it a bit and it looks almost done to me.
> The only issue I can find is that it lets you rename an aggregate by
> using ALTER FUNCTION,
Kohei KaiGai escribió:
> This attached patch is the rebased one towards the latest master branch.
Great, thanks. I played with it a bit and it looks almost done to me.
The only issue I can find is that it lets you rename an aggregate by
using ALTER FUNCTION, which is supposed to be forbidden. (
Kohei KaiGai escribió:
> 2013/1/15 Alvaro Herrera :
> > Kohei KaiGai escribió:
> >
> >> The attached patch is a rebased version towards the latest master
> >> branch, and fix up the issue around error messages on name conflicts.
> >
> > I assume the lock.c changes are just a bollixed merge, right?
2013/1/15 Alvaro Herrera :
> Kohei KaiGai escribió:
>
>> The attached patch is a rebased version towards the latest master
>> branch, and fix up the issue around error messages on name conflicts.
>
> I assume the lock.c changes are just a bollixed merge, right?
>
Yes, I'll check it and rebase it.
Kohei KaiGai escribió:
> The attached patch is a rebased version towards the latest master
> branch, and fix up the issue around error messages on name conflicts.
I assume the lock.c changes are just a bollixed merge, right?
I am not sure about some of the changes in the regression test expected
Tom Lane escribió:
> Robert Haas writes:
> > On Mon, Jan 7, 2013 at 3:43 PM, Alvaro Herrera
> > wrote:
> >> If this is considered a problem, I think the way to fix it is to have a
> >> getObjectDescriptionOids() variant that quotes the object name in the
> >> output.
>
> > This sort of thing h
2013/1/7 Tom Lane :
> Robert Haas writes:
>> On Mon, Jan 7, 2013 at 3:43 PM, Alvaro Herrera
>> wrote:
>>> I checked this patch. It needed a rebase for the changes to return
>>> OIDs. Attached patch applies to current HEAD. In general this looks
>>> good, with one exception: it's using getObje
Robert Haas writes:
> On Mon, Jan 7, 2013 at 3:43 PM, Alvaro Herrera
> wrote:
>> I checked this patch. It needed a rebase for the changes to return
>> OIDs. Attached patch applies to current HEAD. In general this looks
>> good, with one exception: it's using getObjectDescriptionOids() to buil
On Mon, Jan 7, 2013 at 3:43 PM, Alvaro Herrera wrote:
> Kohei KaiGai escribió:
>
>> The attached patch is a revised version.
>>
>> It follows the manner in ExecAlterObjectSchemaStmt(); that tries to check
>> name duplication for object classes that support catcache with name-key.
>> Elsewhere, it
Kohei KaiGai escribió:
> The attached patch is a revised version.
>
> It follows the manner in ExecAlterObjectSchemaStmt(); that tries to check
> name duplication for object classes that support catcache with name-key.
> Elsewhere, it calls individual routines for each object class to solve objec
Kohei KaiGai writes:
> The attached patch is a revised version.
I think you fixed all the problems I could see with your patch. It
applies cleanly (with some offsets), compiles cleanly (I have a custom
Makefile with CUSTOM_COPT=-Werror) and passes regression tests.
I'll go mark it as ready for c
2012/11/19 Dimitri Fontaine :
> Kohei KaiGai writes:
>> OK, Are you suggesting to add a "generic" comments such as "Generic
>> function to change the name of a given object, for simple cases ...",
>> not a list of OBJECT_* at the head of this function, aren't you?
>
> Just something like
>
> * Mo
Kohei KaiGai writes:
> OK, Are you suggesting to add a "generic" comments such as "Generic
> function to change the name of a given object, for simple cases ...",
> not a list of OBJECT_* at the head of this function, aren't you?
Just something like
* Most simple objects are covered by a generi
Hi Dimitri,
Thanks for your checks.
2012/11/19 Dimitri Fontaine :
> Kohei KaiGai writes:
>> The attached patch is the revised version of ALTER RENAME TO
>> consolidation. According to the previous suggestion, it uses
>> a common logic to check object-naming duplication at
>> check_duplicate_obje
Hi,
Thanks for working on that cleanup job!
Kohei KaiGai writes:
> The attached patch is the revised version of ALTER RENAME TO
> consolidation. According to the previous suggestion, it uses
> a common logic to check object-naming duplication at
> check_duplicate_objectname().
I think you need
Kohei KaiGai escribió:
> 2012/10/5 Alvaro Herrera :
> The attached patch fixes the messaging issue.
> I newly add func_signature_string_oid() that returns compatible function's
> signature, but takes its object-id.
>
> So, the error message is now constructed as:
> + case OBJECT_AGGREGATE:
2012/10/2 Alvaro Herrera :
> Excerpts from Alvaro Herrera's message of vie sep 28 18:17:32 -0300 2012:
>> Excerpts from Kohei KaiGai's message of lun sep 10 08:08:32 -0300 2012:
>>
>> > As attached, I split off the original one into three portions; for
>> > set-schema,
>> > set-owner and rename-to
Kohei KaiGai escribió:
> 2012/8/31 Kohei KaiGai :
> > 2012/8/30 Robert Haas :
> >> On Mon, Aug 13, 2012 at 3:35 PM, Kohei KaiGai wrote:
> >>> Was it a right decision to track dependency of large object using
> >>> oid of pg_largeobject, instead of pg_largeobject_metadata?
> >>> IIRC, the reason w
Excerpts from Alvaro Herrera's message of mié oct 03 18:25:54 -0300 2012:
> Excerpts from Kohei KaiGai's message of lun sep 10 08:08:32 -0300 2012:
>
> > As attached, I split off the original one into three portions; for
> > set-schema,
> > set-owner and rename-to. Please apply them in order of p
Excerpts from Kohei KaiGai's message of lun sep 10 08:08:32 -0300 2012:
> As attached, I split off the original one into three portions; for set-schema,
> set-owner and rename-to. Please apply them in order of patch filename.
> Regarding to the error message, RenameErrorMsgAlreadyExists() was adde
Excerpts from Kohei KaiGai's message of lun sep 10 08:08:32 -0300 2012:
> As attached, I split off the original one into three portions; for set-schema,
> set-owner and rename-to. Please apply them in order of patch filename.
Hmm, in the first patch, it seems to me we can simplify
AlterObjectName
Excerpts from Kohei KaiGai's message of lun sep 10 08:08:32 -0300 2012:
> As attached, I split off the original one into three portions; for set-schema,
> set-owner and rename-to. Please apply them in order of patch filename.
> Regarding to the error message, RenameErrorMsgAlreadyExists() was adde
2012/8/30 Robert Haas :
> On Mon, Aug 13, 2012 at 3:35 PM, Kohei KaiGai wrote:
>> The attached patch is a refreshed version of ALTER command
>> reworks towards the latest tree. Here is few big changes except
>> for code integration of the code to rename event triggers.
>
> This seems to have bit-r
On Mon, Aug 13, 2012 at 3:35 PM, Kohei KaiGai wrote:
> The attached patch is a refreshed version of ALTER command
> reworks towards the latest tree. Here is few big changes except
> for code integration of the code to rename event triggers.
This seems to have bit-rotted a bit. Please rebase.
>
29 matches
Mail list logo
