On 2018-Sep-05, Amit Langote wrote:
> On 2018/09/05 1:50, Alvaro Herrera wrote:
> > Proposed patch. Checking isnull in a elog(ERROR) is important, because
> > the column is not marked NOT NULL. This is not true for other columns
> > where we simply do Assert(!isnull).
>
> Looks good. Thanks fo
On 2018/09/05 1:50, Alvaro Herrera wrote:
> Proposed patch. Checking isnull in a elog(ERROR) is important, because
> the column is not marked NOT NULL. This is not true for other columns
> where we simply do Assert(!isnull).
Looks good. Thanks for taking care of other sites as well.
@@ -14705,
On 2018/09/04 21:51, Alvaro Herrera wrote:
> On 2018-Sep-04, Amit Langote wrote:
>
>> On 2018/09/04 13:08, Alvaro Herrera wrote:
>
>>> I think it'd be pointless noise. If we really want to protect against
>>> that, I think we should promote the Assert for relpartbound's isnull
>>> flag into an i
Proposed patch. Checking isnull in a elog(ERROR) is important, because
the column is not marked NOT NULL. This is not true for other columns
where we simply do Assert(!isnull).
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Traini
On 2018-Sep-04, Amit Langote wrote:
> On 2018/09/04 13:08, Alvaro Herrera wrote:
> > I think it'd be pointless noise. If we really want to protect against
> > that, I think we should promote the Assert for relpartbound's isnull
> > flag into an if test.
>
> So that we can elog(ERROR, ...) if is
On 2018/09/04 13:08, Alvaro Herrera wrote:
> On 2018-Sep-04, Amit Langote wrote:
>
>> On 2018/09/04 10:19, Michael Paquier wrote:
>>> On Tue, Sep 04, 2018 at 09:47:07AM +0900, Amit Langote wrote:
On 2018/09/04 6:39, Alvaro Herrera wrote:
> After looking, it seems that this is just self-in
On 2018-Sep-04, Amit Langote wrote:
> On 2018/09/04 10:19, Michael Paquier wrote:
> > On Tue, Sep 04, 2018 at 09:47:07AM +0900, Amit Langote wrote:
> >> On 2018/09/04 6:39, Alvaro Herrera wrote:
> >>> After looking, it seems that this is just self-inflicted pain: for some
> >>> reason, we store th
On 2018/09/04 10:19, Michael Paquier wrote:
> On Tue, Sep 04, 2018 at 09:47:07AM +0900, Amit Langote wrote:
>> On 2018/09/04 6:39, Alvaro Herrera wrote:
>>> After looking, it seems that this is just self-inflicted pain: for some
>>> reason, we store the pg_inherits row for a partition, and immediat
On Tue, Sep 04, 2018 at 09:47:07AM +0900, Amit Langote wrote:
> On 2018/09/04 6:39, Alvaro Herrera wrote:
>> After looking, it seems that this is just self-inflicted pain: for some
>> reason, we store the pg_inherits row for a partition, and immediately
>> afterwards compute and store its partition
On 2018/09/04 6:39, Alvaro Herrera wrote:
> I noticed this strange hack in RelationBuildPartitionDesc:
>
>/*
> * It is possible that the pg_class tuple of a partition has not been
> * updated yet to set its relpartbound field. The only case where
> * this happens i
I noticed this strange hack in RelationBuildPartitionDesc:
/*
* It is possible that the pg_class tuple of a partition has not been
* updated yet to set its relpartbound field. The only case where
* this happens is when we open the parent relation to check using its
11 matches
Mail list logo
