Thread: Re: [PATCHES] Allow the identifier length to be increased via a configure option

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Dhanaraj M wrote:
>> I am sending the patch for the following TODO item:
>> Allow the identifier length to be increased via a configure option

> You should use pg_config.h, not mangle postgres_ext.h like that.  Or
> maybe generate postgres_ext.h from an hypotetical postgres_ext.h.in (but
> I wouldn't do that, really).

I'm wondering how this got into the TODO list.  It seems rather
pointless, and likely to create client compatibility problems (if not,
why is NAMEDATALEN exported at all?)

A bigger problem with the proposed patch is that it makes it look like
you can set the identifier length to any random number; the restrictions
mentioned in postgres_ext.h aren't enforced or even displayed to the
user of configure.

            regards, tom lane

Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>
>> Dhanaraj M wrote:
>>
>>> I am sending the patch for the following TODO item:
>>> Allow the identifier length to be increased via a configure option
>>>
>
>
>> You should use pg_config.h, not mangle postgres_ext.h like that.  Or
>> maybe generate postgres_ext.h from an hypotetical postgres_ext.h.in (but
>> I wouldn't do that, really).
>>
>
> I'm wondering how this got into the TODO list.  It seems rather
> pointless, and likely to create client compatibility problems (if not,
> why is NAMEDATALEN exported at all?)
>
Will this TODO item be removed from the list?
Or I shall proceed with the suggestions given.

Thanks
Dhanaraj

Dhanaraj M wrote:
> Tom Lane wrote:
> > Alvaro Herrera <alvherre@commandprompt.com> writes:
> >
> >> Dhanaraj M wrote:
> >>
> >>> I am sending the patch for the following TODO item:
> >>> Allow the identifier length to be increased via a configure option
> >>>
> >
> >
> >> You should use pg_config.h, not mangle postgres_ext.h like that.  Or
> >> maybe generate postgres_ext.h from an hypotetical postgres_ext.h.in (but
> >> I wouldn't do that, really).
> >>
> >
> > I'm wondering how this got into the TODO list.  It seems rather
> > pointless, and likely to create client compatibility problems (if not,
> > why is NAMEDATALEN exported at all?)
> >
> Will this TODO item be removed from the list?
> Or I shall proceed with the suggestions given.

TODO item removed.

--
  Bruce Momjian   bruce@momjian.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:
> I'm wondering how this got into the TODO list.  It seems rather
> pointless, and likely to create client compatibility problems (if
> not, why is NAMEDATALEN exported at all?)

I think because it used to be used in libpq's notification structure.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> ... why is NAMEDATALEN exported at all?)

> I think because it used to be used in libpq's notification structure.

Yeah, you're probably right.  Maybe we should take it out of
postgres_ext.h and move it to pg_config_manual.h.  If no one complains
after a release cycle or so, we could reconsider making it configurable
more easily.

            regards, tom lane

Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Tom Lane wrote:
> >> ... why is NAMEDATALEN exported at all?)
>
> > I think because it used to be used in libpq's notification structure.
>
> Yeah, you're probably right.  Maybe we should take it out of
> postgres_ext.h and move it to pg_config_manual.h.  If no one complains
> after a release cycle or so, we could reconsider making it configurable
> more easily.

Added to TODO:

    * Move NAMEDATALEN from postgres_ext.h to pg_config_manual.h and
      consider making it more configurable in future releases

--
  Bruce Momjian   bruce@momjian.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +