On Fri, Apr 22, 2016 at 4:52 AM, Tom Lane wrote:
> I wrote:
>> Perhaps I'm missing something, but if so, in what way is the
>> "#if _MSC_VER >= 1600" stanza not totally useless given the
>> immediately preceding macro redefinitions?
>
> Some rummaging in the git history says that that stanza did s
I wrote:
> Perhaps I'm missing something, but if so, in what way is the
> "#if _MSC_VER >= 1600" stanza not totally useless given the
> immediately preceding macro redefinitions?
Some rummaging in the git history says that that stanza did something
when it was added (in 63876d3ba), but the later c
Jeevan Chalke wrote:
> I found some dead code in CREATE/RENAME ROLE code path.
>
> We have introduced RoleSpec and handled public and none role names in
> grammar
> itself. We do have these handling in CreateRole() and RenameRole()
> which is NO more valid now.
Right.
> Attached patch to remov
On 02/19/2015 05:34 AM, Michael Paquier wrote:
I noticed that the following structures are still defined in
gin_private.h but they are used nowhere since 2c03216d that has
reworked WAL format:
- ginxlogSplitEntry
- ginxlogSplitDataLeaf
- ginxlogSplitDataInternal
Attached is a trivial patch to rem
On Fri, Sep 20, 2013 at 12:13:18AM +0100, Greg Stark wrote:
> So I'm just going to make the code defensive and assume NULL is possible when
> if maybe it isn't.
>
> In case it's not clear, this is one of the thing's Xi Wang's took picked up.
> There not to many but it turns out they are indeed not
So I'm just going to make the code defensive and assume NULL is possible
when if maybe it isn't.
In case it's not clear, this is one of the thing's Xi Wang's took picked
up. There not to many but it turns out they are indeed not all in the adt
code so I might wait until after the commit fest to co
On Wed, Sep 18, 2013 at 6:20 PM, Greg Stark wrote:
> The following code is in the ProcSleep at proc.c:1138.
> GetBlockingAutoVacuumPgproc() should presumably always return a vacuum
> pgproc entry since the deadlock state says it's blocked by autovacuum.
> But I'm not really familiar enough with th
Gregory Stark <[EMAIL PROTECTED]> writes:
> Let me put it another way, how would I write a test case to cover these lines
> of code and not receive an error from replanning?
"Hard to get to" is not the same as "dead code". An example is that
third-party add-ons might re-use plans that are not com
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Should this case at heaptuple.c:1606 be turned into an elog() now that we
>> have
>> plan cache invalidation?
>
> No, I think it's good as-is. Reading the column as null is the correct
> behavior.
Isn't the c
Gregory Stark <[EMAIL PROTECTED]> writes:
> Should this case at heaptuple.c:1606 be turned into an elog() now that we have
> plan cache invalidation?
No, I think it's good as-is. Reading the column as null is the correct
behavior.
regards, tom lane
--
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Bruce Momjian wrote:
OK, would you please send a patch to remove the unused code. Thanks.
Ok, here you are.
Applied with an added comment and Assert.
While testing it I realized that there seems to be a nearby bug in
_bt_find
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> OK, would you please send a patch to remove the unused code. Thanks.
> Ok, here you are.
Applied with an added comment and Assert.
While testing it I realized that there seems to be a nearby bug in
_bt_findsplitloc: it fai
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Heikki, did this code cleanup get included in your recent btree split
fix?
No.
OK, would you please send a patch to remove the unused code. Thanks.
Ok, here you are.
--
Heikki Linnakangas
EnterpriseDB http://www.en
Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > Heikki, did this code cleanup get included in your recent btree split
> > fix?
>
> No.
OK, would you please send a patch to remove the unused code. Thanks.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
Bruce Momjian wrote:
Heikki, did this code cleanup get included in your recent btree split
fix?
No.
---
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
In that case, newitemleft would be false, right?
I'
Heikki, did this code cleanup get included in your recent btree split
fix?
---
Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > In that case, newitemleft would be false, right?
> > I'm saying the piece ma
On Tue, Sep 05, 2006 at 01:42:57PM +0100, Gregory Stark wrote:
> Martijn van Oosterhout writes:
>
> > attlen -2 is used for cstring (null terminated strings).
> >
> > Hope this helps,
>
> Well that's what the code I quoted indicates. But when do we ever store a
> cstring in a tuple? Certainly I
On Tue, Sep 05, 2006 at 01:21:46PM +0100, Gregory Stark wrote:
>
>
>
> Is there anywhere we make use of this code that handles attlen == -2?
>
> If so I'm curious where because I was thinking of doing something similar and
> didn't realise we already had this capability. But I suspect it's just
Martijn van Oosterhout writes:
> attlen -2 is used for cstring (null terminated strings).
>
> Hope this helps,
Well that's what the code I quoted indicates. But when do we ever store a
cstring in a tuple? Certainly I can't find any standard data types that use
it.
--
Gregory Stark
Enterpri
19 matches
Mail list logo
