Due to Tom's feedback:
This has been saved for the 8.3 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---------------------------------------------------------------------------
Dhanaraj M wrote:
>
> 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.
>
>
> Dhanaraj M wrote:
>
> > Hi all,
> >
> > This patch was discussed a few months ago.
> > I could not complete this patch at that time.
> > I hope that the current version of my patch is acceptable.
> >
> > Patch details:
> > **************
> > 1. Assign a new field called 'Seq Value' for \ds command
> > 2. All the sequence values are '1' initially
> > 3. After executing the query, call AssignSeqValue()
> > 4. This function assigns the respective sequence values back to the
> > resultset
> >
> >
> > Please review and comment on this patch.
> >
> > Thanks
> > Dhanaraj
> >
> > Tom Lane wrote:
> >
> >> Dhanaraj M <Dhanaraj.M@Sun.COM> writes:
> >>
> >>
> >>> However, it was not possible to display the seq. value using this.
> >>> Hence, I made a small change in the currval() function, so that it
> >>> retrieves the last_value
> >>> even if the the value is not cached.
> >>>
> >>
> >>
> >> Breaking currval()'s semantics is not an acceptable solution for this.
> >>
> >> The best, fully backward compatible solution is for psql to issue
> >> "SELECT last_value FROM <seq>" queries to get the values. This might
> >> be a bit tricky to wedge into the structure of describe.c, but I don't
> >> see any fundamental reason why it can't be done.
> >>
> >> regards, tom lane
> >>
> >>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
