Обсуждение: Re: [PATCHES] Have psql show current sequnce values - (Resubmission)

Поиск
Список
Период
Сортировка

Re: [PATCHES] Have psql show current sequnce values - (Resubmission)

От
Tom Lane
Дата:
Dhanaraj M <Dhanaraj.M@Sun.COM> writes:
> Sorry for resubmitting this patch.
> Just now I found a problem.
> Instead of assigning initial sequence value to 1,
> I assign LLONG_MAX to avoid the buffer overflow problem.
> Please find the current version here.

This patch is a mess.  In the first place, it's completely unkosher for
an application to scribble on a PGresult's contents, even if you do take
steps like the above to try to make sure there's enough space.  But said
step does not work anyway -- LLONG_MAX might not exist on the client, or
might exist but be smaller than the server's value.

Another problem with it is it's not schema-aware and not proof against
quoting requirements for the sequence name (try it with a mixed-case
sequence name for instance).  It also ought to pay some attention to
the possibility that the SELECT for last_value fails --- quite aside
from communication failure or such, there might be a permissions problem
preventing the last_value from being read.

            regards, tom lane

Re: [PATCHES] Have psql show current sequnce values - (Resubmission)

От
Bruce Momjian
Дата:
Based on this patch review, I am removing the patch from the patch
queue and requiring a resubmission.

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

Tom Lane wrote:
> Dhanaraj M <Dhanaraj.M@Sun.COM> writes:
> > Sorry for resubmitting this patch.
> > Just now I found a problem.
> > Instead of assigning initial sequence value to 1,
> > I assign LLONG_MAX to avoid the buffer overflow problem.
> > Please find the current version here.
>
> This patch is a mess.  In the first place, it's completely unkosher for
> an application to scribble on a PGresult's contents, even if you do take
> steps like the above to try to make sure there's enough space.  But said
> step does not work anyway -- LLONG_MAX might not exist on the client, or
> might exist but be smaller than the server's value.
>
> Another problem with it is it's not schema-aware and not proof against
> quoting requirements for the sequence name (try it with a mixed-case
> sequence name for instance).  It also ought to pay some attention to
> the possibility that the SELECT for last_value fails --- quite aside
> from communication failure or such, there might be a permissions problem
> preventing the last_value from being read.
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match

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

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