On 2019/01/13 16:56, Michael Paquier wrote:
> On Fri, Jan 11, 2019 at 04:04:41PM +0900, Michael Paquier wrote:
>> Thanks. I can commit this version if there are no objections then.
>
> And done.
Thank you!
Regards,
Amit
On Fri, Jan 11, 2019 at 04:04:41PM +0900, Michael Paquier wrote:
> Thanks. I can commit this version if there are no objections then.
And done.
--
Michael
signature.asc
Description: PGP signature
On Fri, Jan 11, 2019 at 10:50:32AM +0900, Amit Langote wrote:
> Okay, I withdraw my objection to the wording proposed by you.
Thanks. I can commit this version if there are no objections then.
--
Michael
signature.asc
Description: PGP signature
On 2019/01/10 19:27, Michael Paquier wrote:
> On Thu, Jan 10, 2019 at 05:58:10PM +0900, Amit Langote wrote:
>> The reason I started this thread is due to this Stack Overflow question:
>>
>> https://stackoverflow.com/questions/53554727/logical-replication-and-declarative-partitioning-in-postgresql-1
On Thu, Jan 10, 2019 at 05:58:10PM +0900, Amit Langote wrote:
> The reason I started this thread is due to this Stack Overflow question:
>
> https://stackoverflow.com/questions/53554727/logical-replication-and-declarative-partitioning-in-postgresql-11
>
> So, it appears that there may be an eleme
Hi,
On 2019/01/10 17:46, Arkhena wrote:
>> Your rewritten version is perhaps fine, although I remain a bit concerned
>> that some users might be puzzled when they see this error, that is, if
>> they interpret the message as "it's impossible to use a partitioned table
>> as logical replication targ
> > On Tue, Jan 08, 2019 at 04:42:35PM +0900, Michael Paquier wrote:
> >> I can see your point, though I would stick with
> >> ERRCODE_WRONG_OBJECT_TYPE for consistency with the existing code and
> >> because the code is intended to not work on anything else than plain
> >> tables, at least now.
>
On 2019/01/10 14:25, Michael Paquier wrote:
> On Tue, Jan 08, 2019 at 04:42:35PM +0900, Michael Paquier wrote:
>> I can see your point, though I would stick with
>> ERRCODE_WRONG_OBJECT_TYPE for consistency with the existing code and
>> because the code is intended to not work on anything else than
On Tue, Jan 08, 2019 at 04:42:35PM +0900, Michael Paquier wrote:
> I can see your point, though I would stick with
> ERRCODE_WRONG_OBJECT_TYPE for consistency with the existing code and
> because the code is intended to not work on anything else than plain
> tables, at least now.
Attached are my s
On Tue, Jan 08, 2019 at 03:05:42PM +0900, Amit Langote wrote:
> I meant to say that the feature to add relations to a subscription is not
> supported for certain relation types, even though it's practically
> *possible* to do so. But maybe, I'm misunderstanding the error code
> selection policy.
On 2019/01/08 13:44, Michael Paquier wrote:
> On Tue, Jan 08, 2019 at 01:13:11PM +0900, Amit Langote wrote:
>> Yeah, I think so too. I also noticed that the patch uses
>> ERRCODE_WRONG_OBJECT_TYPE as the error code, whereas we may want to use
>> ERRCODE_FEATURE_NOT_SUPPORTED. Thoughts on that?
>
On Tue, Jan 08, 2019 at 01:13:11PM +0900, Amit Langote wrote:
> Yeah, I think so too. I also noticed that the patch uses
> ERRCODE_WRONG_OBJECT_TYPE as the error code, whereas we may want to use
> ERRCODE_FEATURE_NOT_SUPPORTED. Thoughts on that?
ERRCODE_WRONG_OBJECT_TYPE is the right call I thi
On 2019/01/08 11:10, Michael Paquier wrote:
> On Mon, Jan 07, 2019 at 05:28:27PM +0900, Amit Langote wrote:
>> On 2019/01/07 16:35, Michael Paquier wrote:
>>> It seems to me that we may want something more like:
>>> Primary: "could not use \"%s.%s\" as logical replication target".
>>> Detail: "Rela
On Mon, Jan 07, 2019 at 05:28:27PM +0900, Amit Langote wrote:
> On 2019/01/07 16:35, Michael Paquier wrote:
>> It seems to me that we may want something more like:
>> Primary: "could not use \"%s.%s\" as logical replication target".
>> Detail: "Relation %s.%s is a foreign table", "not a table", etc
On 2019/01/07 16:35, Michael Paquier wrote:
> On Mon, Jan 07, 2019 at 01:49:49PM +0900, Amit Langote wrote:
>> {
>> /*
>> - * We currently only support writing to regular tables.
>> + * We currently only support writing to regular tables. However, give
>> + * a more specific erro
On Mon, Jan 07, 2019 at 01:49:49PM +0900, Amit Langote wrote:
> {
> /*
> - * We currently only support writing to regular tables.
> + * We currently only support writing to regular tables. However, give
> + * a more specific error for partitioned and foreign tables.
>
Thanks for reviewing.
On 2018/12/31 20:23, Peter Eisentraut wrote:
> On 06/12/2018 05:46, Amit Langote wrote:
>> /*
>> * We currently only support writing to regular tables.
>> */
>
> I think that comment should stay above the code you are adding.
Do you mean to keep it at the t
On 06/12/2018 05:46, Amit Langote wrote:
> /*
>* We currently only support writing to regular tables.
>*/
I think that comment should stay above the code you are adding.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remot
On 2018/12/06 13:19, Michael Paquier wrote:
> On Thu, Dec 06, 2018 at 11:34:19AM +0900, Amit Langote wrote:
>> Adding to January CF.
>
> Okay, that looks good to me based on your arguments upthread.
Thanks for looking.
> A
> small-ish comment I have is that you could use a set of if/else if
> co
On Thu, Dec 06, 2018 at 11:34:19AM +0900, Amit Langote wrote:
> Adding to January CF.
Okay, that looks good to me based on your arguments upthread. A
small-ish comment I have is that you could use a set of if/else if
conditions instead of separate ifs.
--
Michael
signature.asc
Description: PGP
On 2018/12/06 11:28, Amit Langote wrote:
> On 2018/12/05 10:28, Amit Langote wrote:
>> On 2018/12/05 10:20, Michael Paquier wrote:
>>> On Tue, Dec 04, 2018 at 09:25:09AM +0100, Magnus Hagander wrote:
I think more people would directly understand the "is not a table" for a
foreign table th
On 2018/12/05 10:28, Amit Langote wrote:
> On 2018/12/05 10:20, Michael Paquier wrote:
>> On Tue, Dec 04, 2018 at 09:25:09AM +0100, Magnus Hagander wrote:
>>> I think more people would directly understand the "is not a table" for a
>>> foreign table than a partitioned one (for example, it does now
On 2018/12/05 10:20, Michael Paquier wrote:
> On Tue, Dec 04, 2018 at 09:25:09AM +0100, Magnus Hagander wrote:
>> I think more people would directly understand the "is not a table" for a
>> foreign table than a partitioned one (for example, it does now show up in
>> \dt or under tables in pgadmin,
On Tue, Dec 04, 2018 at 09:25:09AM +0100, Magnus Hagander wrote:
> I think more people would directly understand the "is not a table" for a
> foreign table than a partitioned one (for example, it does now show up in
> \dt or under tables in pgadmin, but partitioned ones do). That said, if
> it's no
On Tue, Dec 4, 2018 at 3:38 AM Amit Langote
wrote:
> On 2018/12/04 11:23, Michael Paquier wrote:
> > On Tue, Dec 04, 2018 at 10:51:40AM +0900, Amit Langote wrote:
> >> Okay, here is a patch. I didn't find any tests in subscription.sql
> >> related to unsupported relkinds, so didn't bother adding
On 2018/12/04 11:23, Michael Paquier wrote:
> On Tue, Dec 04, 2018 at 10:51:40AM +0900, Amit Langote wrote:
>> Okay, here is a patch. I didn't find any tests in subscription.sql
>> related to unsupported relkinds, so didn't bother adding one for this case
>> either.
>
> Should we care about other
On Tue, Dec 04, 2018 at 10:51:40AM +0900, Amit Langote wrote:
> Okay, here is a patch. I didn't find any tests in subscription.sql
> related to unsupported relkinds, so didn't bother adding one for this case
> either.
Should we care about other relkinds as well?
--
Michael
signature.asc
Descrip
On 2018/12/03 17:51, Magnus Hagander wrote:
> On Mon, Dec 3, 2018 at 7:39 AM Tatsuo Ishii wrote:
>>> Could we improve the error message that's output when the subscription
>>> target relation is a partitioned table? Currently, we get:
>>>
>>> ERROR: logical replication target relation "public.fo
On Mon, Dec 3, 2018 at 7:39 AM Tatsuo Ishii wrote:
> > Hi,
> >
> > Could we improve the error message that's output when the subscription
> > target relation is a partitioned table? Currently, we get:
> >
> > ERROR: logical replication target relation "public.foo" is not a table
> >
> > I think
> Hi,
>
> Could we improve the error message that's output when the subscription
> target relation is a partitioned table? Currently, we get:
>
> ERROR: logical replication target relation "public.foo" is not a table
>
> I think it'd be more helpful to get:
>
> ERROR: "public.foo" is a partit
30 matches
Mail list logo
