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

2007-02-13 Thread 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 [EMAIL PROTECTED] 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  [EMAIL PROTECTED]  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

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

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


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

2006-09-04 Thread Tom Lane
Dhanaraj M [EMAIL PROTECTED] 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