Re: Minor inheritance/check bug: Inconsistent behavior
On Thu, 6 Sep 2012 14:50:05 -0400 Robert Hass wrote:
On Tue, Aug 28, 2012 at 6:40 AM, Amit Kapila <amit(dot)kapila(at)huawei(dot)com> wrote:
AFAICT during Update also, it doesn't contain useful. The only chance it
would have contain something useful is when it goes for EvalPlanQual and
then again comes to check for constraints. However these attributes get
filled in heap_update much later.So now should the fix be that it returns an error for system column
reference except for OID case?
+1.
1. I think in this scenario the error for system column except for tableOID should be thrown at Create/Alter time.
2. After setting OID in ExecInsert/ExecUpdate may be setting of same inside heap functions can be removed.
But for now I have kept them as it is.
Please find the Patch for bug-fix.
If this is okay, I shall send you the test cases for same.
With Regards,
Amit Kapila.
Attachments:
system_col_constr.patchtext/plain; name=system_col_constr.patchDownload+20-0
Sorry, earlier sent below mail on hackers instead of bugs list. Just forwarding the same here.
________________________________________
From: pgsql-hackers-owner@postgresql.org [pgsql-hackers-owner@postgresql.org] on behalf of Amit kapila [amit.kapila@huawei.com]
Sent: Friday, September 14, 2012 7:34 PM
To: robertmhaas@gmail.com
Cc: tgl@sss.pgh.pa.us; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Minor inheritance/check bug: Inconsistent behavior
On Thu, 6 Sep 2012 14:50:05 -0400 Robert Hass wrote:
On Tue, Aug 28, 2012 at 6:40 AM, Amit Kapila <amit(dot)kapila(at)huawei(dot)com> wrote:
AFAICT during Update also, it doesn't contain useful. The only chance it
would have contain something useful is when it goes for EvalPlanQual and
then again comes to check for constraints. However these attributes get
filled in heap_update much later.So now should the fix be that it returns an error for system column
reference except for OID case?
+1.
1. I think in this scenario the error for system column except for tableOID should be thrown at Create/Alter time.
2. After setting OID in ExecInsert/ExecUpdate may be setting of same inside heap functions can be removed.
But for now I have kept them as it is.
Please find the Patch for bug-fix.
If this is okay, I shall send you the test cases for same.
With Regards,
Amit Kapila.
On Fri, Sep 14, 2012 at 02:04:51PM +0000, Amit kapila wrote:
On Thu, 6 Sep 2012 14:50:05 -0400 Robert Hass wrote:
On Tue, Aug 28, 2012 at 6:40 AM, Amit Kapila <amit(dot)kapila(at)huawei(dot)
com> wrote:AFAICT during Update also, it doesn't contain useful. The only chance it
would have contain something useful is when it goes for EvalPlanQual and
then again comes to check for constraints. However these attributes get
filled in heap_update much later.So now should the fix be that it returns an error for system column
reference except for OID case?+1.
1. I think in this scenario the error for system column except for tableOID
should be thrown at Create/Alter time.2. After setting OID in ExecInsert/ExecUpdate may be setting of same inside
heap functions can be removed.But for now I have kept them as it is.
Please find the Patch for bug-fix.
If this is okay, I shall send you the test cases for same.
Did we ever make any progress on this?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Friday, January 25, 2013 8:36 PM Bruce Momjian wrote:
On Fri, Sep 14, 2012 at 02:04:51PM +0000, Amit kapila wrote:
On Thu, 6 Sep 2012 14:50:05 -0400 Robert Hass wrote:
On Tue, Aug 28, 2012 at 6:40 AM, Amit Kapila
<amit(dot)kapila(at)huawei(dot)
com> wrote:
AFAICT during Update also, it doesn't contain useful. The only
chance it
would have contain something useful is when it goes for
EvalPlanQual and
then again comes to check for constraints. However these
attributes get
filled in heap_update much later.
So now should the fix be that it returns an error for system
column
reference except for OID case?
+1.
1. I think in this scenario the error for system column except for
tableOID
should be thrown at Create/Alter time.
2. After setting OID in ExecInsert/ExecUpdate may be setting of same
inside
heap functions can be removed.
But for now I have kept them as it is.
Please find the Patch for bug-fix.
If this is okay, I shall send you the test cases for same.
Did we ever make any progress on this?
I have done the initial analysis and prepared a patch, don't know if
anything more I can do until
someone can give any suggestions to further proceed on this bug.
With Regards,
Amit Kapila.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Jan 26, 2013 at 11:31:49AM +0530, Amit Kapila wrote:
On Friday, January 25, 2013 8:36 PM Bruce Momjian wrote:
On Fri, Sep 14, 2012 at 02:04:51PM +0000, Amit kapila wrote:
On Thu, 6 Sep 2012 14:50:05 -0400 Robert Hass wrote:
On Tue, Aug 28, 2012 at 6:40 AM, Amit Kapila
<amit(dot)kapila(at)huawei(dot)
com> wrote:
AFAICT during Update also, it doesn't contain useful. The only
chance it
would have contain something useful is when it goes for
EvalPlanQual and
then again comes to check for constraints. However these
attributes get
filled in heap_update much later.
So now should the fix be that it returns an error for system
column
reference except for OID case?
+1.
1. I think in this scenario the error for system column except for
tableOID
should be thrown at Create/Alter time.
2. After setting OID in ExecInsert/ExecUpdate may be setting of same
inside
heap functions can be removed.
But for now I have kept them as it is.
Please find the Patch for bug-fix.
If this is okay, I shall send you the test cases for same.
Did we ever make any progress on this?
I have done the initial analysis and prepared a patch, don't know if
anything more I can do until
someone can give any suggestions to further proceed on this bug.
So, I guess we never figured this out.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Saturday, June 29, 2013 4:58 AM Bruce Momjian wrote:
On Sat, Jan 26, 2013 at 11:31:49AM +0530, Amit Kapila wrote:
On Friday, January 25, 2013 8:36 PM Bruce Momjian wrote:
On Fri, Sep 14, 2012 at 02:04:51PM +0000, Amit kapila wrote:
On Thu, 6 Sep 2012 14:50:05 -0400 Robert Hass wrote:
On Tue, Aug 28, 2012 at 6:40 AM, Amit Kapila
<amit(dot)kapila(at)huawei(dot)
com> wrote:
AFAICT during Update also, it doesn't contain useful. The only
chance it
would have contain something useful is when it goes for
EvalPlanQual and
then again comes to check for constraints. However these
attributes get
filled in heap_update much later.
So now should the fix be that it returns an error for system
column
reference except for OID case?
+1.
1. I think in this scenario the error for system column except for
tableOID
should be thrown at Create/Alter time.
2. After setting OID in ExecInsert/ExecUpdate may be setting of same
inside
heap functions can be removed.
But for now I have kept them as it is.
Please find the Patch for bug-fix.
If this is okay, I shall send you the test cases for same.
Did we ever make any progress on this?
I have done the initial analysis and prepared a patch, don't know if
anything more I can do until
someone can give any suggestions to further proceed on this bug.
So, I guess we never figured this out.
I can submit this bug-fix for next commitfest if there is no objection for doing so.
What is your opinion?
With Regards,
Amit Kapila.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, Jun 30, 2013 at 06:57:10AM +0000, Amit kapila wrote:
I have done the initial analysis and prepared a patch, don't know if
anything more I can do until
someone can give any suggestions to further proceed on this bug.So, I guess we never figured this out.
I can submit this bug-fix for next commitfest if there is no objection for doing so.
What is your opinion?
Yes, good idea.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers