Thread: Willing to fix a TODO case in libpq module

Willing to fix a TODO case in libpq module

From
"Wu, Fei"
Date:

Hi,all

 

On website: https://wiki.postgresql.org/wiki/Todo#libpq

I found that in libpq module,there is a todo case:

-------------------------------------------------------------------------------

Prevent PQfnumber() from lowercasing unquoted column names

PQfnumber() should never have been doing lowercasing, but historically it has so we need a way to prevent it

 

-------------------------------------------------------------------------------

I am interested in this one. So ,Had it be fixed?

If not, I am willing to do so.

In that way ,could anyone tell me the detail features of this function it supported to be?

I will try to fix it~

 

 

--

Best Regards

-----------------------------------------------------

Wu Fei

Development Department II

Software Division III

Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)

ADDR.: No.6 Wenzhu Road, Software Avenue,

       Nanjing, 210012, China

TEL  : +86+25-86630566-9356

COINS: 7998-9356

FAX: +86+25-83317685

MAIL:wufei.fnst@cn.fujitsu.com

http://www.fujitsu.com/cn/fnst/

---------------------------------------------------

 

Re: Willing to fix a TODO case in libpq module

From
Tom Lane
Date:
"Wu, Fei" <wufei.fnst@cn.fujitsu.com> writes:
> On website: https://wiki.postgresql.org/wiki/Todo#libpq
> I found that in libpq module,there is a todo case:
> -------------------------------------------------------------------------------
> Prevent PQfnumber() from lowercasing unquoted column names
> PQfnumber() should never have been doing lowercasing, but historically it has so we need a way to prevent it

> -------------------------------------------------------------------------------
> I am interested in this one. So ,Had it be fixed?

Hmm, I think this item might be obsolete.  The existing definition that
PQfnumber performs quote-stripping and down-casing is a bit overcomplicated,
but it's not impossible to work with.  It's pretty hard to call it a bug,
so I don't think we'd consider actually changing the function's behavior.

Maybe there's room for a second function with a different name that
just looks for an exact match to the input string.  But I've heard
few if any requests for that.  The use-case for PQfnumber is pretty
narrow to begin with --- I suspect most apps just hard-wire the expected
column number --- so the demand for a marginally-more-efficient version
would be even narrower.

            regards, tom lane