Re: current version: Patch - Have psql show current values for a sequence]

Dhanaraj M <Dhanaraj(dot)M(at)Sun(dot)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

Tom Lane wrote:

>Dhanaraj M <Dhanaraj(dot)M(at)Sun(dot)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

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(dot)M(at)Sun(dot)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(dot)M(at)Sun(dot)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. +

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/

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. +

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

Dhanaraj M <Dhanaraj(dot)M(at)Sun(dot)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

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(dot)M(at)Sun(dot)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
>
>

Dhanaraj M wrote:
> 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.

What is this patch supposed to be doing?

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

For \ds command,
this patch displays the current sequence value(last_value) for each
sequence.
This was suggested during the earlier discussion.

Output of the current patch:
--------------------------------------
mydb=# \ds
List of relations
Schema | Name | Type | Owner | Seq Value
--------+------+----------+----------+-----------
public | a | sequence | Dhanaraj | 5
public | b | sequence | Dhanaraj | 2
public | c | sequence | Dhanaraj | 1
(3 rows)

output without aplying the patch
--------------------------------------------
mydb=# \ds
List of relations
Schema | Name | Type | Owner
--------+------+----------+----------+-----
public | a | sequence | Dhanaraj
public | b | sequence | Dhanaraj
public | c | sequence | Dhanaraj
(3 rows)

Peter Eisentraut wrote:

>Dhanaraj M wrote:
>
>
>>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.
>>
>>
>
>What is this patch supposed to be doing?
>
>
>

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(dot)M(at)Sun(dot)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
>>
>>

Dhanaraj M <Dhanaraj(dot)M(at)Sun(dot)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

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(dot)M(at)Sun(dot)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(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

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

Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

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

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(dot)M(at)Sun(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

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

Bruce Momjian wrote:
>
> Your patch has been added to the PostgreSQL unapplied patches list at:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches
>
> It will be applied as soon as one of the PostgreSQL committers reviews
> and approves it.

I think the SELECT query is short on quoting and schema-qualification
for the target sequence.

Also it should probably be adjusted to use strlcpy instead of strcpy.
Coding style seems a bit off. Also, since this is likely to be
expensive, it may be better to show the value only on \dS+, not plain
\dS.

Not sure what else. That's what jumps at me.

I think we discussed replacing the current sequence representation with
a single relation that would contain all sequences in the database, so
that you could do "select * from pg_sequence" and get all the values in
one go. The idea was considered not implementable at the time due to us
not having "non transactional relations", but I'd suggest adding it to
the TODO so that we don't forget later.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera wrote:
> Bruce Momjian wrote:
> >
> > Your patch has been added to the PostgreSQL unapplied patches list at:
> >
> > http://momjian.postgresql.org/cgi-bin/pgpatches
> >
> > It will be applied as soon as one of the PostgreSQL committers reviews
> > and approves it.
>
> I think the SELECT query is short on quoting and schema-qualification
> for the target sequence.
>
> Also it should probably be adjusted to use strlcpy instead of strcpy.
> Coding style seems a bit off. Also, since this is likely to be
> expensive, it may be better to show the value only on \dS+, not plain
> \dS.
>
> Not sure what else. That's what jumps at me.

Yep, for a small patch, it needs major cleanups.

> I think we discussed replacing the current sequence representation with
> a single relation that would contain all sequences in the database, so
> that you could do "select * from pg_sequence" and get all the values in
> one go. The idea was considered not implementable at the time due to us
> not having "non transactional relations", but I'd suggest adding it to
> the TODO so that we don't forget later.

OK:

* Consider placing all sequences in a single table, now that system
tables are full transactional

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

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

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> I think we discussed replacing the current sequence representation with
> a single relation that would contain all sequences in the database, so
> that you could do "select * from pg_sequence" and get all the values in
> one go. The idea was considered not implementable at the time due to us
> not having "non transactional relations", but I'd suggest adding it to
> the TODO so that we don't forget later.

I wonder if we could kluge it by making all sequences inheritance
children of a dummy "pg_sequence" relation. Or perhaps better,
implement this as a system view on a set-returning function --- if there
are lots of sequences the planner's not likely to help you much anyway.

regards, tom lane

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > I think we discussed replacing the current sequence representation with
> > a single relation that would contain all sequences in the database, so
> > that you could do "select * from pg_sequence" and get all the values in
> > one go. The idea was considered not implementable at the time due to us
> > not having "non transactional relations", but I'd suggest adding it to
> > the TODO so that we don't forget later.
>
> I wonder if we could kluge it by making all sequences inheritance
> children of a dummy "pg_sequence" relation. Or perhaps better,
> implement this as a system view on a set-returning function --- if there
> are lots of sequences the planner's not likely to help you much anyway.

I like the system view best.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

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

Based on this patch review, I am removing the patch from the patch
queue and requiring a resubmission.

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

Tom Lane wrote:
> Dhanaraj M <Dhanaraj(dot)M(at)Sun(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

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

Patch removed from queue based on patch review. Resubmit.

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

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(dot)M(at)Sun(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

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