Re: Refactor textToQualifiedNameList() - Mailing list pgsql-hackers

From Yugo Nagata
Subject Re: Refactor textToQualifiedNameList()
Date
Msg-id 20180829135039.ade8db2872553bd206aa147a@sraoss.co.jp
Whole thread Raw
In response to Re: Refactor textToQualifiedNameList()  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: Refactor textToQualifiedNameList()
Re: Refactor textToQualifiedNameList()
List pgsql-hackers
On Tue, 28 Aug 2018 11:49:26 +0900 (Tokyo Standard Time)
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote:

> At Fri, 24 Aug 2018 20:44:12 +0900, Yugo Nagata <nagata@sraoss.co.jp> wrote in
<20180824204412.150979ae6b283ddb639f93f6@sraoss.co.jp>
> > When working on other patch[1], I found there are almost same
> > functions, texttoQualifiedNameList() and stringToQualifiedNameList().
> > The only difference is the argument type, text or char*. I don't know
> > why these functions are defined seperately, but I think the former 
> > function can be rewritten using the latter code as the attached patch.
> > Is this reasonable fix?
> 
> The functions were introduced within a month for different
> objectives in March and April, 2002. I supppose that they are
> intentionally added as separate functions for simplicitly since
> the second one is apparent CnP'ed from the first one.
> 
> commit 5f4745adf4fb2a1f933b25d7a2bc72b39fa9edfd
> commit 52200befd04b9fa71da83231c808764867079226

Thank you for your comments. I also looked at the commit history.
stringToQNL is added after textToQNL as a static function originally,
but this is now public and reffered from other modules, too.  So, I 
propose to mote this from regproc.c to verlena.c and rewrite textToQNL
to call stringToQNL.  This is just for reducing redundancy of the code. 
Attached is the updated patch.
 
> Returning to the patch, the downside of it is that textToQNL
> makes an extra and unused copy of the parameter string. (It's a
> kind of bug that it is forgetting to free rawname.)

I also fixed to free rawname in the texttoQNL.

Regards,

-- 
Yugo Nagata <nagata@sraoss.co.jp>

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: buildfarm: could not read block 3 in file "base/16384/2662":read only 0 of 8192 bytes
Next
From: Peter Eisentraut
Date:
Subject: Re: "Write amplification" is made worse by "getting tired" whileinserting into nbtree secondary indexes (Was: Why B-Tree suffix truncationmatters)