SEO

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Dhanaraj M <Dhanaraj.M@Sun.COM> writes:
> sorry for sending the old version in the previous mail . Here I attach
> the recent version of the patch file.

Surely this problem does not require adding any server-side code.
Something like "select last_value from <seq>" would be more appropriate;
and it'd have some hope of working with back-version servers.

Also, please use something more helpful than "***" as the column
header. Your urge to add a footnote to explain it shows that you
didn't try hard enough to devise a good header to begin with.

[ btw, both fmgroids.h and fmgrtab.c are generated files. Patching
them is unnecessary and inappropriate. ]

regards, tom lane

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

http://archives.postgresql.org

Tom Lane wrote:

>Dhanaraj M <Dhanaraj.M@Sun.COM> writes:
>
>
>>sorry for sending the old version in the previous mail . Here I attach
>>the recent version of the patch file.
>>
>>
>----------------------------------------------------------------------
>
>
Surely this problem does not require adding any server-side code.

>Something like "select last_value from <seq>" would be more appropriate;
>and it'd have some hope of working with back-version servers.
>
>Also, please use something more helpful than "***" as the column
>header. Your urge to add a footnote to explain it shows that you
>didn't try hard enough to devise a good header to begin with.
>
>[ btw, both fmgroids.h and fmgrtab.c are generated files. Patching
>them is unnecessary and inappropriate. ]
>
----------------------------------------------------------

The existing functions like lastval, currval dont provide the current
sequence value always.
They work only if the sequence is already cached (nextval is called
atleast once for that sequence).
Changing the internals of lastval/currval will give the solution.
However, I feel that the functionality change
may affect the customers who use the current version.

Hence, I am sure that it requires the server side change. There are two
options here
1. Modifying the exisitng functions (or) 2. adding new functions


Thanks for your review
Dhanaraj



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

As Tom asked, why not use seqname.last_value? Looking at your output:

+ if (showSeq && !showTables)
+ appendPQExpBuffer(&buf,
+ ",\n curval(c.oid) as \"%s\""
+ ",\n CASE curvalcheck(c.oid) WHEN '1' THEN '%s' WHEN '0' THEN '%s' END as \"%s\"",
+ _("value"),_(" ***"),_(""),_("Start from"));

What do you want to show that seqname.last_value doesn't give you?
Curval? I don't see that as useful for a psql display. Now that I look
at the TODO item:

o Have psql show current values for a sequence

It is confusing. It means "the current values" for the sequence, not
"curval" for the sequence. I don't even understand what your function
is returning. Just stick to last_value, though I think
seqname.is_called might be what you were looking for.

What fields do we want to show? Maybe the TODO item is not needed. Is
this all we want to show?

test=> \x
Expanded display is on.

test=> select * from xx;
-[ RECORD 1 ]-+--------------------
sequence_name | xx
last_value | 1
increment_by | 1
max_value | 9223372036854775807
min_value | 1
cache_value | 1
log_cnt | 32
is_cycled | f
is_called | t


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

Dhanaraj M wrote:
> Tom Lane wrote:
>
> >Dhanaraj M <Dhanaraj.M@Sun.COM> writes:
> >
> >
> >>sorry for sending the old version in the previous mail . Here I attach
> >>the recent version of the patch file.
> >>
> >>
> >----------------------------------------------------------------------
> >
> >
> Surely this problem does not require adding any server-side code.
>
> >Something like "select last_value from <seq>" would be more appropriate;
> >and it'd have some hope of working with back-version servers.
> >
> >Also, please use something more helpful than "***" as the column
> >header. Your urge to add a footnote to explain it shows that you
> >didn't try hard enough to devise a good header to begin with.
> >
> >[ btw, both fmgroids.h and fmgrtab.c are generated files. Patching
> >them is unnecessary and inappropriate. ]
> >
> ----------------------------------------------------------
>
> The existing functions like lastval, currval dont provide the current
> sequence value always.
> They work only if the sequence is already cached (nextval is called
> atleast once for that sequence).
> Changing the internals of lastval/currval will give the solution.
> However, I feel that the functionality change
> may affect the customers who use the current version.
>
> Hence, I am sure that it requires the server side change. There are two
> options here
> 1. Modifying the exisitng functions (or) 2. adding new functions
>
>
> Thanks for your review
> Dhanaraj
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +
Dhanaraj M wrote:
> Tom Lane wrote:
>
> >Dhanaraj M <Dhanaraj.M@Sun.COM> writes:
> >
> >
> >>sorry for sending the old version in the previous mail . Here I attach
> >>the recent version of the patch file.
> >>
> >>
> >----------------------------------------------------------------------
> >
> >
> Surely this problem does not require adding any server-side code.
>
> >Something like "select last_value from <seq>" would be more appropriate;
> >and it'd have some hope of working with back-version servers.
> >
> >Also, please use something more helpful than "***" as the column
> >header. Your urge to add a footnote to explain it shows that you
> >didn't try hard enough to devise a good header to begin with.
> >
> >[ btw, both fmgroids.h and fmgrtab.c are generated files. Patching
> >them is unnecessary and inappropriate. ]
> >
> ----------------------------------------------------------
>
> The existing functions like lastval, currval dont provide the current
> sequence value always.
> They work only if the sequence is already cached (nextval is called
> atleast once for that sequence).
> Changing the internals of lastval/currval will give the solution.
> However, I feel that the functionality change
> may affect the customers who use the current version.
>
> Hence, I am sure that it requires the server side change. There are two
> options here
> 1. Modifying the exisitng functions (or) 2. adding new functions
>
>
> Thanks for your review
> Dhanaraj
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Bruce Momjian wrote:

> What fields do we want to show? Maybe the TODO item is not needed. Is
> this all we want to show?
>
IRC what we want is something like this.

regression=# \d abc
Sequence "public.abc"
Column | Type
--------------+---------
sequence_name | abc
last_value | 1
increment_by | 1
max_value | 9223372036854775807
min_value | 1
cache_value | 1
log_cnt | 1
is_cycled | f
is_called | f


Because "\d abc" doesn't show us any important information.

regression=# \d abc
Sequence "public.abc"
Column | Type
---------------+---------
sequence_name | name
last_value | bigint
increment_by | bigint
max_value | bigint
min_value | bigint
cache_value | bigint
log_cnt | bigint
is_cycled | boolean
is_called | boolean


Last year, I made a patch for this but it was so ugly that I didn't send
to -patches. Maybe Bruce's solution (\x & select * from seq) could be
hardcoded in describe.c.

--
Euler Taveira de Oliveira
http://www.timbira.com/

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

I am thinking we just add another column to the \d display for sequences
showing the current value.

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

Euler Taveira de Oliveira wrote:
> Bruce Momjian wrote:
>
> > What fields do we want to show? Maybe the TODO item is not needed. Is
> > this all we want to show?
> >
> IRC what we want is something like this.
>
> regression=# \d abc
> Sequence "public.abc"
> Column | Type
> --------------+---------
> sequence_name | abc
> last_value | 1
> increment_by | 1
> max_value | 9223372036854775807
> min_value | 1
> cache_value | 1
> log_cnt | 1
> is_cycled | f
> is_called | f
>
>
> Because "\d abc" doesn't show us any important information.
>
> regression=# \d abc
> Sequence "public.abc"
> Column | Type
> ---------------+---------
> sequence_name | name
> last_value | bigint
> increment_by | bigint
> max_value | bigint
> min_value | bigint
> cache_value | bigint
> log_cnt | bigint
> is_cycled | boolean
> is_called | boolean
>
>
> Last year, I made a patch for this but it was so ugly that I didn't send
> to -patches. Maybe Bruce's solution (\x & select * from seq) could be
> hardcoded in describe.c.
>
> --
> Euler Taveira de Oliveira
> http://www.timbira.com/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Bruce Momjian wrote:

>I am thinking we just add another column to the \d display for sequences
>showing the current value.
>
>---------------------------------------------------------------------------
>
>
>
As suggested in the previous mails, I tried to use the following to
display the seq. value.
select last_value from <seq>.

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.

I hope this patch will be more suitable for this issue. Pl. look at the
patch.

Thanks
Dhanaraj



---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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

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 4: Have you searched our list archives?

http://archives.postgresql.org