small psql patch - show Schema name for \dt \dv \dS

I can't remember who said they were working on schema related psql
changes, but I kept finding myself wishing I could see what schema a
table or view exists in when I use \dt, \dv, etc. So, here is a patch
which does just that.

It sorts on "Schema" first, and "Name" second.

It also changes the test for system objects to key off the namespace
name starting with 'pg_' instead of the object name.

Sample output:

test=# create schema testschema;
CREATE SCHEMA
test=# create view testschema.ts_view as select 1;
CREATE VIEW
test=# \dv
List of relations
Name | Schema | Type | Owner
--------------------+------------+------+----------
__testpassbyval | public | view | postgres
fooview | public | view | postgres
master_pg_proc | public | view | postgres
rmt_pg_proc | public | view | postgres
vw_dblink_get_pkey | public | view | postgres
vw_dblink_replace | public | view | postgres
ts_view | testschema | view | postgres
(7 rows)

If there are no objections, please apply.

Thanks!

Joe

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

http://candle.pha.pa.us/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

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

Joe Conway wrote:
> I can't remember who said they were working on schema related psql
> changes, but I kept finding myself wishing I could see what schema a
> table or view exists in when I use \dt, \dv, etc. So, here is a patch
> which does just that.
>
> It sorts on "Schema" first, and "Name" second.
>
> It also changes the test for system objects to key off the namespace
> name starting with 'pg_' instead of the object name.
>
> Sample output:
>
> test=# create schema testschema;
> CREATE SCHEMA
> test=# create view testschema.ts_view as select 1;
> CREATE VIEW
> test=# \dv
> List of relations
> Name | Schema | Type | Owner
> --------------------+------------+------+----------
> __testpassbyval | public | view | postgres
> fooview | public | view | postgres
> master_pg_proc | public | view | postgres
> rmt_pg_proc | public | view | postgres
> vw_dblink_get_pkey | public | view | postgres
> vw_dblink_replace | public | view | postgres
> ts_view | testschema | view | postgres
> (7 rows)
>
> If there are no objections, please apply.
>
> Thanks!
>
> Joe
>

> Index: src/bin/psql/describe.c
> ===================================================================
> RCS file: /opt/src/cvs/pgsql/src/bin/psql/describe.c,v
> retrieving revision 1.55
> diff -c -r1.55 describe.c
> *** src/bin/psql/describe.c 12 Jul 2002 18:43:19 -0000 1.55
> --- src/bin/psql/describe.c 18 Jul 2002 21:53:52 -0000
> ***************
> *** 1022,1030 ****
>
> printfPQExpBuffer(&buf,
> "SELECT c.relname as \"%s\",\n"
> " CASE c.relkind WHEN 'r' THEN '%s' WHEN 'v' THEN '%s' WHEN 'i' THEN '%s' WHEN 'S' THEN '%s' WHEN 's' THEN '%s' END as \"%s\",\n"
> " u.usename as \"%s\"",
> ! _("Name"), _("table"), _("view"), _("index"), _("sequence"),
> _("special"), _("Type"), _("Owner"));
>
> if (desc)
> --- 1022,1031 ----
>
> printfPQExpBuffer(&buf,
> "SELECT c.relname as \"%s\",\n"
> + " n.nspname as \"%s\",\n"
> " CASE c.relkind WHEN 'r' THEN '%s' WHEN 'v' THEN '%s' WHEN 'i' THEN '%s' WHEN 'S' THEN '%s' WHEN 's' THEN '%s' END as \"%s\",\n"
> " u.usename as \"%s\"",
> ! _("Name"), _("Schema"), _("table"), _("view"), _("index"), _("sequence"),
> _("special"), _("Type"), _("Owner"));
>
> if (desc)
> ***************
> *** 1034,1047 ****
> if (showIndexes)
> appendPQExpBuffer(&buf,
> ",\n c2.relname as \"%s\""
> ! "\nFROM pg_class c, pg_class c2, pg_index i, pg_user u\n"
> "WHERE c.relowner = u.usesysid\n"
> "AND i.indrelid = c2.oid AND i.indexrelid = c.oid\n",
> _("Table"));
> else
> appendPQExpBuffer(&buf,
> ! "\nFROM pg_class c, pg_user u\n"
> ! "WHERE c.relowner = u.usesysid\n");
>
> appendPQExpBuffer(&buf, "AND c.relkind IN (");
> if (showTables)
> --- 1035,1050 ----
> if (showIndexes)
> appendPQExpBuffer(&buf,
> ",\n c2.relname as \"%s\""
> ! "\nFROM pg_class c, pg_class c2, pg_index i, pg_user u, pg_namespace n\n"
> "WHERE c.relowner = u.usesysid\n"
> + "AND c.relnamespace = n.oid\n"
> "AND i.indrelid = c2.oid AND i.indexrelid = c.oid\n",
> _("Table"));
> else
> appendPQExpBuffer(&buf,
> ! "\nFROM pg_class c, pg_user u, pg_namespace n\n"
> ! "WHERE c.relowner = u.usesysid\n"
> ! "AND c.relnamespace = n.oid\n");
>
> appendPQExpBuffer(&buf, "AND c.relkind IN (");
> if (showTables)
> ***************
> *** 1058,1071 ****
> appendPQExpBuffer(&buf, ")\n");
>
> if (showSystem)
> ! appendPQExpBuffer(&buf, " AND c.relname ~ '^pg_'\n");
> else
> ! appendPQExpBuffer(&buf, " AND c.relname !~ '^pg_'\n");
>
> if (name)
> appendPQExpBuffer(&buf, " AND c.relname ~ '^%s'\n", name);
>
> ! appendPQExpBuffer(&buf, "ORDER BY 1;");
>
> res = PSQLexec(buf.data);
> termPQExpBuffer(&buf);
> --- 1061,1074 ----
> appendPQExpBuffer(&buf, ")\n");
>
> if (showSystem)
> ! appendPQExpBuffer(&buf, " AND n.nspname ~ '^pg_'\n");
> else
> ! appendPQExpBuffer(&buf, " AND n.nspname !~ '^pg_'\n");
>
> if (name)
> appendPQExpBuffer(&buf, " AND c.relname ~ '^%s'\n", name);
>
> ! appendPQExpBuffer(&buf, "ORDER BY 2,1;");
>
> res = PSQLexec(buf.data);
> termPQExpBuffer(&buf);

>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

Patch applied. Thanks.

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

Joe Conway wrote:
> I can't remember who said they were working on schema related psql
> changes, but I kept finding myself wishing I could see what schema a
> table or view exists in when I use \dt, \dv, etc. So, here is a patch
> which does just that.
>
> It sorts on "Schema" first, and "Name" second.
>
> It also changes the test for system objects to key off the namespace
> name starting with 'pg_' instead of the object name.
>
> Sample output:
>
> test=# create schema testschema;
> CREATE SCHEMA
> test=# create view testschema.ts_view as select 1;
> CREATE VIEW
> test=# \dv
> List of relations
> Name | Schema | Type | Owner
> --------------------+------------+------+----------
> __testpassbyval | public | view | postgres
> fooview | public | view | postgres
> master_pg_proc | public | view | postgres
> rmt_pg_proc | public | view | postgres
> vw_dblink_get_pkey | public | view | postgres
> vw_dblink_replace | public | view | postgres
> ts_view | testschema | view | postgres
> (7 rows)
>
> If there are no objections, please apply.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

Joe Conway <mail(at)joeconway(dot)com> writes:
> It sorts on "Schema" first, and "Name" second.

> Sample output:
> List of relations
> Name | Schema | Type | Owner
> --------------------+------------+------+----------
> __testpassbyval | public | view | postgres
> fooview | public | view | postgres
> master_pg_proc | public | view | postgres
> rmt_pg_proc | public | view | postgres
> vw_dblink_get_pkey | public | view | postgres
> vw_dblink_replace | public | view | postgres
> ts_view | testschema | view | postgres

It seems rather odd and confusing that the sort order takes the second
column as the major key. I think that the sort ordering should be
column 1 then 2. That means either putting the schema column first,
or keeping this column ordering and sorting on relname before schema.
I lean towards the first choice but can see a case for the second.

regards, tom lane

Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>
>>It sorts on "Schema" first, and "Name" second.
>
>
>>Sample output:
>> List of relations
>> Name | Schema | Type | Owner
>>--------------------+------------+------+----------
>> __testpassbyval | public | view | postgres
>> fooview | public | view | postgres
>> master_pg_proc | public | view | postgres
>> rmt_pg_proc | public | view | postgres
>> vw_dblink_get_pkey | public | view | postgres
>> vw_dblink_replace | public | view | postgres
>> ts_view | testschema | view | postgres
>
>
> It seems rather odd and confusing that the sort order takes the second
> column as the major key. I think that the sort ordering should be
> column 1 then 2. That means either putting the schema column first,
> or keeping this column ordering and sorting on relname before schema.
> I lean towards the first choice but can see a case for the second.
>
> regards, tom lane

OK -- I see your point on the second option, but I also lean towards the
first. I'll change it to schema column first, order by column 1 then 2.

Joe

Tom Lane wrote:
> It seems rather odd and confusing that the sort order takes the second
> column as the major key.

Maybe I'm a rather odd and confused kind of guy ;-)

> I think that the sort ordering should be
> column 1 then 2. That means either putting the schema column first,
> or keeping this column ordering and sorting on relname before schema.
> I lean towards the first choice but can see a case for the second.

Here's another small patch, to implement Tom's first choice above. I
looked at re-adding your own "pg_temp_n" schema back into the results.
But I don't see a way to determine your own BackendId unless we add a
builtin function to expose MyBackendId as a user callable function.
Should we do this, or did I just miss something?

If there are no objections, please apply.

Thanks,

Joe

Joe Conway <mail(at)joeconway(dot)com> writes:
> I looked at re-adding your own "pg_temp_n" schema back into the results.
> But I don't see a way to determine your own BackendId unless we add a
> builtin function to expose MyBackendId as a user callable function.
> Should we do this, or did I just miss something?

I don't think it's important. Real soon now we will be changing psql's
queries to take visibility into account directly (cf my comments to
Greg Mullane yesterday). That should take care of making one's temp
tables visible, I think; and if not we can address the issue at that
time.

regards, tom lane

I just added pg_stat_get_backend_mypid() that returns the pid. Does
that help you?

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

Joe Conway wrote:
> Tom Lane wrote:
> > It seems rather odd and confusing that the sort order takes the second
> > column as the major key.
>
> Maybe I'm a rather odd and confused kind of guy ;-)
>
> > I think that the sort ordering should be
> > column 1 then 2. That means either putting the schema column first,
> > or keeping this column ordering and sorting on relname before schema.
> > I lean towards the first choice but can see a case for the second.
>
> Here's another small patch, to implement Tom's first choice above. I
> looked at re-adding your own "pg_temp_n" schema back into the results.
> But I don't see a way to determine your own BackendId unless we add a
> builtin function to expose MyBackendId as a user callable function.
> Should we do this, or did I just miss something?
>
> If there are no objections, please apply.
>
> Thanks,
>
> Joe

> Index: src/bin/psql/describe.c
> ===================================================================
> RCS file: /opt/src/cvs/pgsql/src/bin/psql/describe.c,v
> retrieving revision 1.56
> diff -c -r1.56 describe.c
> *** src/bin/psql/describe.c 20 Jul 2002 05:57:31 -0000 1.56
> --- src/bin/psql/describe.c 20 Jul 2002 20:57:16 -0000
> ***************
> *** 1021,1031 ****
> initPQExpBuffer(&buf);
>
> printfPQExpBuffer(&buf,
> ! "SELECT c.relname as \"%s\",\n"
> ! " n.nspname as \"%s\",\n"
> " CASE c.relkind WHEN 'r' THEN '%s' WHEN 'v' THEN '%s' WHEN 'i' THEN '%s' WHEN 'S' THEN '%s' WHEN 's' THEN '%s' END as \"%s\",\n"
> " u.usename as \"%s\"",
> ! _("Name"), _("Schema"), _("table"), _("view"), _("index"), _("sequence"),
> _("special"), _("Type"), _("Owner"));
>
> if (desc)
> --- 1021,1031 ----
> initPQExpBuffer(&buf);
>
> printfPQExpBuffer(&buf,
> ! "SELECT n.nspname as \"%s\",\n"
> ! " c.relname as \"%s\",\n"
> " CASE c.relkind WHEN 'r' THEN '%s' WHEN 'v' THEN '%s' WHEN 'i' THEN '%s' WHEN 'S' THEN '%s' WHEN 's' THEN '%s' END as \"%s\",\n"
> " u.usename as \"%s\"",
> ! _("Schema"), _("Name"), _("table"), _("view"), _("index"), _("sequence"),
> _("special"), _("Type"), _("Owner"));
>
> if (desc)
> ***************
> *** 1068,1074 ****
> if (name)
> appendPQExpBuffer(&buf, " AND c.relname ~ '^%s'\n", name);
>
> ! appendPQExpBuffer(&buf, "ORDER BY 2,1;");
>
> res = PSQLexec(buf.data);
> termPQExpBuffer(&buf);
> --- 1068,1074 ----
> if (name)
> appendPQExpBuffer(&buf, " AND c.relname ~ '^%s'\n", name);
>
> ! appendPQExpBuffer(&buf, "ORDER BY 1,2;");
>
> res = PSQLexec(buf.data);
> termPQExpBuffer(&buf);

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

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

Bruce Momjian wrote:
> I just added pg_stat_get_backend_mypid() that returns the pid. Does
> that help you?

Sorry for the slow response.

Backend pid doesn't solve this issue, because the temp schema name for a
logged-in user is based on MyBackendId, not pid, i.e. your temp schema
name is something like pg_temp_1 when MyBackendId = 1, etc. It would be
easy enough to write a function exposing this, the question is whether
it is desirable to expose it?

Joe

Joe Conway wrote:
> Bruce Momjian wrote:
> > I just added pg_stat_get_backend_mypid() that returns the pid. Does
> > that help you?
>
> Sorry for the slow response.
>
> Backend pid doesn't solve this issue, because the temp schema name for a
> logged-in user is based on MyBackendId, not pid, i.e. your temp schema
> name is something like pg_temp_1 when MyBackendId = 1, etc. It would be
> easy enough to write a function exposing this, the question is whether
> it is desirable to expose it?

I see pg_stat_get_backend_idset() and pg_stat_get_backend_pid(), seems we
should report the slot of the current backend.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

>> Backend pid doesn't solve this issue, because the temp schema name for a
>> logged-in user is based on MyBackendId, not pid, i.e. your temp schema
>> name is something like pg_temp_1 when MyBackendId = 1, etc. It would be
>> easy enough to write a function exposing this, the question is whether
>> it is desirable to expose it?

I see no reason to do so at all.

What you want is not the BackendId; what you want is the temp schema
name, and current_schemas() can tell you that.

But so far I haven't seen any convincing argument why any client query
would really want to look at current_schemas(), either. What you
actually want to know about is visibility, and computing that from
current_schemas() is quite an expensive proposition. I think what
we need to expose is RelationIsVisible and friends, not BackendId.

regards, tom lane

Tom Lane wrote:
> >> Backend pid doesn't solve this issue, because the temp schema name for a
> >> logged-in user is based on MyBackendId, not pid, i.e. your temp schema
> >> name is something like pg_temp_1 when MyBackendId = 1, etc. It would be
> >> easy enough to write a function exposing this, the question is whether
> >> it is desirable to expose it?
>
> I see no reason to do so at all.
>
> What you want is not the BackendId; what you want is the temp schema
> name, and current_schemas() can tell you that.
>
> But so far I haven't seen any convincing argument why any client query
> would really want to look at current_schemas(), either. What you
> actually want to know about is visibility, and computing that from
> current_schemas() is quite an expensive proposition. I think what
> we need to expose is RelationIsVisible and friends, not BackendId.

Well, if we are going to reach 7.3, we had better figure out what we are
doing in this area. Let's start talking.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

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

http://candle.pha.pa.us/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

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

Joe Conway wrote:
> Tom Lane wrote:
> > It seems rather odd and confusing that the sort order takes the second
> > column as the major key.
>
> Maybe I'm a rather odd and confused kind of guy ;-)
>
> > I think that the sort ordering should be
> > column 1 then 2. That means either putting the schema column first,
> > or keeping this column ordering and sorting on relname before schema.
> > I lean towards the first choice but can see a case for the second.
>
> Here's another small patch, to implement Tom's first choice above. I
> looked at re-adding your own "pg_temp_n" schema back into the results.
> But I don't see a way to determine your own BackendId unless we add a
> builtin function to expose MyBackendId as a user callable function.
> Should we do this, or did I just miss something?
>
> If there are no objections, please apply.
>
> Thanks,
>
> Joe

> Index: src/bin/psql/describe.c
> ===================================================================
> RCS file: /opt/src/cvs/pgsql/src/bin/psql/describe.c,v
> retrieving revision 1.56
> diff -c -r1.56 describe.c
> *** src/bin/psql/describe.c 20 Jul 2002 05:57:31 -0000 1.56
> --- src/bin/psql/describe.c 20 Jul 2002 20:57:16 -0000
> ***************
> *** 1021,1031 ****
> initPQExpBuffer(&buf);
>
> printfPQExpBuffer(&buf,
> ! "SELECT c.relname as \"%s\",\n"
> ! " n.nspname as \"%s\",\n"
> " CASE c.relkind WHEN 'r' THEN '%s' WHEN 'v' THEN '%s' WHEN 'i' THEN '%s' WHEN 'S' THEN '%s' WHEN 's' THEN '%s' END as \"%s\",\n"
> " u.usename as \"%s\"",
> ! _("Name"), _("Schema"), _("table"), _("view"), _("index"), _("sequence"),
> _("special"), _("Type"), _("Owner"));
>
> if (desc)
> --- 1021,1031 ----
> initPQExpBuffer(&buf);
>
> printfPQExpBuffer(&buf,
> ! "SELECT n.nspname as \"%s\",\n"
> ! " c.relname as \"%s\",\n"
> " CASE c.relkind WHEN 'r' THEN '%s' WHEN 'v' THEN '%s' WHEN 'i' THEN '%s' WHEN 'S' THEN '%s' WHEN 's' THEN '%s' END as \"%s\",\n"
> " u.usename as \"%s\"",
> ! _("Schema"), _("Name"), _("table"), _("view"), _("index"), _("sequence"),
> _("special"), _("Type"), _("Owner"));
>
> if (desc)
> ***************
> *** 1068,1074 ****
> if (name)
> appendPQExpBuffer(&buf, " AND c.relname ~ '^%s'\n", name);
>
> ! appendPQExpBuffer(&buf, "ORDER BY 2,1;");
>
> res = PSQLexec(buf.data);
> termPQExpBuffer(&buf);
> --- 1068,1074 ----
> if (name)
> appendPQExpBuffer(&buf, " AND c.relname ~ '^%s'\n", name);
>
> ! appendPQExpBuffer(&buf, "ORDER BY 1,2;");
>
> res = PSQLexec(buf.data);
> termPQExpBuffer(&buf);

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

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

It appears this patch was already applied, I think by Tom Lane.

Thanks.

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

Joe Conway wrote:
> Tom Lane wrote:
> > It seems rather odd and confusing that the sort order takes the second
> > column as the major key.
>
> Maybe I'm a rather odd and confused kind of guy ;-)
>
> > I think that the sort ordering should be
> > column 1 then 2. That means either putting the schema column first,
> > or keeping this column ordering and sorting on relname before schema.
> > I lean towards the first choice but can see a case for the second.
>
> Here's another small patch, to implement Tom's first choice above. I
> looked at re-adding your own "pg_temp_n" schema back into the results.
> But I don't see a way to determine your own BackendId unless we add a
> builtin function to expose MyBackendId as a user callable function.
> Should we do this, or did I just miss something?
>
> If there are no objections, please apply.
>
> Thanks,
>
> Joe

> Index: src/bin/psql/describe.c
> ===================================================================
> RCS file: /opt/src/cvs/pgsql/src/bin/psql/describe.c,v
> retrieving revision 1.56
> diff -c -r1.56 describe.c
> *** src/bin/psql/describe.c 20 Jul 2002 05:57:31 -0000 1.56
> --- src/bin/psql/describe.c 20 Jul 2002 20:57:16 -0000
> ***************
> *** 1021,1031 ****
> initPQExpBuffer(&buf);
>
> printfPQExpBuffer(&buf,
> ! "SELECT c.relname as \"%s\",\n"
> ! " n.nspname as \"%s\",\n"
> " CASE c.relkind WHEN 'r' THEN '%s' WHEN 'v' THEN '%s' WHEN 'i' THEN '%s' WHEN 'S' THEN '%s' WHEN 's' THEN '%s' END as \"%s\",\n"
> " u.usename as \"%s\"",
> ! _("Name"), _("Schema"), _("table"), _("view"), _("index"), _("sequence"),
> _("special"), _("Type"), _("Owner"));
>
> if (desc)
> --- 1021,1031 ----
> initPQExpBuffer(&buf);
>
> printfPQExpBuffer(&buf,
> ! "SELECT n.nspname as \"%s\",\n"
> ! " c.relname as \"%s\",\n"
> " CASE c.relkind WHEN 'r' THEN '%s' WHEN 'v' THEN '%s' WHEN 'i' THEN '%s' WHEN 'S' THEN '%s' WHEN 's' THEN '%s' END as \"%s\",\n"
> " u.usename as \"%s\"",
> ! _("Schema"), _("Name"), _("table"), _("view"), _("index"), _("sequence"),
> _("special"), _("Type"), _("Owner"));
>
> if (desc)
> ***************
> *** 1068,1074 ****
> if (name)
> appendPQExpBuffer(&buf, " AND c.relname ~ '^%s'\n", name);
>
> ! appendPQExpBuffer(&buf, "ORDER BY 2,1;");
>
> res = PSQLexec(buf.data);
> termPQExpBuffer(&buf);
> --- 1068,1074 ----
> if (name)
> appendPQExpBuffer(&buf, " AND c.relname ~ '^%s'\n", name);
>
> ! appendPQExpBuffer(&buf, "ORDER BY 1,2;");
>
> res = PSQLexec(buf.data);
> termPQExpBuffer(&buf);

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

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073