Thread

Couple document fixes

Thom Brown <thom@linux.com> — 2011-01-19T18:05:59Z

Hi,

I've attached a couple minor fixes to the docs.  One relating to
SECURITY LABEL and the other for pg_class.relpersistence

-- 
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

Re: [HACKERS] Couple document fixes

Kevin Grittner <kevin.grittner@wicourts.gov> — 2011-01-19T18:11:31Z

Thom Brown <thom@linux.com> wrote:
 
> I've attached a couple minor fixes to the docs.  One relating to
> SECURITY LABEL and the other for pg_class.relpersistence
 
relpersistence should be <type>"char"</type>, not <type>char</type>.
Oddly enough, there is a difference.
 
-Kevin

Re: [HACKERS] Couple document fixes

Thom Brown <thom@linux.com> — 2011-01-19T18:29:53Z

On 19 January 2011 18:11, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote:
> Thom Brown <thom@linux.com> wrote:
>
>> I've attached a couple minor fixes to the docs.  One relating to
>> SECURITY LABEL and the other for pg_class.relpersistence
>
> relpersistence should be <type>"char"</type>, not <type>char</type>.
> Oddly enough, there is a difference.
>
> -Kevin

relkind in the same table is the same type, but isn't displayed as
"char" in the docs, and the same applies to many other system tables.
They would need changing too then.

Examples are:

pg_type.typtype
pg_proc.provolatile
pg_attribute.attstorage

-- 
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

Re: [HACKERS] Couple document fixes

Kevin Grittner <kevin.grittner@wicourts.gov> — 2011-01-19T18:53:18Z

Thom Brown <thom@linux.com> wrote:

> relkind in the same table is the same type, but isn't displayed as
> "char" in the docs, and the same applies to many other system
tables.
> They would need changing too then.
> 
> Examples are:
> 
> pg_type.typtype
> pg_proc.provolatile
> pg_attribute.attstorage

That's a good point.  Consistency would trump getting a single entry
right, for sure.  I wonder, though, whether we shouldn't
consistently distinguish them.  For one thing, I've seen multiple
posts where people were reporting "bugs" because of having confused
char with "char".

FWIW, \d shows:

       Table "pg_catalog.pg_class"
     Column      |   Type    | Modifiers
-----------------+-----------+-----------
 relname         | name      | not null
 relnamespace    | oid       | not null
 reltype         | oid       | not null
 reloftype       | oid       | not null
 relowner        | oid       | not null
 relam           | oid       | not null
 relfilenode     | oid       | not null
 reltablespace   | oid       | not null
 relpages        | integer   | not null
 reltuples       | real      | not null
 reltoastrelid   | oid       | not null
 reltoastidxid   | oid       | not null
 relhasindex     | boolean   | not null
 relisshared     | boolean   | not null
 relpersistence  | "char"    | not null
 relkind         | "char"    | not null
 relnatts        | smallint  | not null
 relchecks       | smallint  | not null
 relhasoids      | boolean   | not null
 relhaspkey      | boolean   | not null
 relhasexclusion | boolean   | not null
 relhasrules     | boolean   | not null
 relhastriggers  | boolean   | not null
 relhassubclass  | boolean   | not null
 relfrozenxid    | xid       | not null
 relacl          | aclitem[] |
 reloptions      | text[]    |
Indexes:
    "pg_class_oid_index" UNIQUE, btree (oid)
    "pg_class_relname_nsp_index" UNIQUE, btree (relname,
relnamespace)

Currently we don't seem to distinguish them in very many places in
the docs:

$ find -name '*.sgml' | xargs egrep -n '\"char\"'
./doc/src/sgml/textsearch.sgml:1271:setweight(<replaceable
class="PARAMETER">vector</replaceable> <type>tsvector</>,
<replaceable class="PARAMETER">weight</replaceable> <type>"char"</>)
returns <type>tsvector</>
./doc/src/sgml/datatype.sgml:1116:    length might change in a
future release. The type <type>"char"</type>
./doc/src/sgml/datatype.sgml:1134:       
<entry><type>"char"</type></entry>
./doc/src/sgml/release-old.sgml:4406:Add routines for single-byte
"char" type(Thomas)
./doc/src/sgml/release-old.sgml:4747:Make "char" type a synonym for
"char(1)" (actually implemented as bpchar)(Thomas)
./doc/src/sgml/xfunc.sgml:1794:        
<entry><type>"char"</type></entry>
./doc/src/sgml/release-8.0.sgml:3389:      <type>"char"</> data type
have been removed.
./doc/src/sgml/release-8.0.sgml:4460:        <type>"char"</> data
type have been removed.
./doc/src/sgml/release-8.0.sgml:4466:        to do arithmetic on a
<type>"char"</> column, you can cast it to
./doc/src/sgml/func.sgml:8462:        
<literal><function>setweight(<type>tsvector</>,
<type>"char"</>)</function></literal>
./doc/src/sgml/btree-gin.sgml:17:  <type>oid</>, <type>money</>,
<type>"char"</>,

-Kevin

Re: [HACKERS] Couple document fixes

Tom Lane <tgl@sss.pgh.pa.us> — 2011-01-19T21:10:07Z

Thom Brown <thom@linux.com> writes:
> I've attached a couple minor fixes to the docs.  One relating to
> SECURITY LABEL and the other for pg_class.relpersistence

Applied, thanks.

			regards, tom lane

Re: [HACKERS] Couple document fixes

Thom Brown <thom@linux.com> — 2011-01-19T21:11:12Z

On 19 January 2011 21:10, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thom Brown <thom@linux.com> writes:
>> I've attached a couple minor fixes to the docs.  One relating to
>> SECURITY LABEL and the other for pg_class.relpersistence
>
> Applied, thanks.

Cheers Mr Lane.

-- 
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

Re: [HACKERS] Couple document fixes

Bruce Momjian <bruce@momjian.us> — 2011-03-11T11:13:20Z

Kevin Grittner wrote:
> Thom Brown <thom@linux.com> wrote:
>  
> > I've attached a couple minor fixes to the docs.  One relating to
> > SECURITY LABEL and the other for pg_class.relpersistence
>  
> relpersistence should be <type>"char"</type>, not <type>char</type>.
> Oddly enough, there is a difference.

I am unsure on that one.  We have many 'char' mentions in catalog.sgml,
and I don't see any of them shown as '"char"'.  (Wow, we should have
just called this type char1, but I think that name came from Berkeley!) 
The big problem is that the pg_type name is really "char" _without_
quotes.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

Re: Couple document fixes

Alvaro Herrera <alvherre@commandprompt.com> — 2011-03-11T15:23:22Z

Removing CC to pg-docs so that Robert reads it.

Excerpts from Bruce Momjian's message of vie mar 11 08:13:20 -0300 2011:
> Kevin Grittner wrote:

> > relpersistence should be <type>"char"</type>, not <type>char</type>.
> > Oddly enough, there is a difference.
> 
> I am unsure on that one.  We have many 'char' mentions in catalog.sgml,
> and I don't see any of them shown as '"char"'.  (Wow, we should have
> just called this type char1, but I think that name came from Berkeley!) 
> The big problem is that the pg_type name is really "char" _without_
> quotes.

One idea is to rename the type to something else.  We could keep "char"
as an alias for backwards compatibility, but use the new name in system
catalogs, and document it as the main name of the type.

Discussed the idea a bit on IM with Bruce, but couldn't find any really
good alternative.  Idea floated so far:

* byte (seems pretty decent to me)
* octet (though maybe people would expect it'd output as a number)
* char1 (looks ugly, but then we have int4 and so on)
* achar (this one is just plain weird)

None seems great.  Thoughts?

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Re: Couple document fixes

Tom Lane <tgl@sss.pgh.pa.us> — 2011-03-11T15:40:50Z

Alvaro Herrera <alvherre@commandprompt.com> writes:
> One idea is to rename the type to something else.  We could keep "char"
> as an alias for backwards compatibility, but use the new name in system
> catalogs, and document it as the main name of the type.

We don't have type aliases...

			regards, tom lane

Re: Couple document fixes

Alvaro Herrera <alvherre@commandprompt.com> — 2011-03-11T15:51:47Z

Excerpts from Tom Lane's message of vie mar 11 12:40:50 -0300 2011:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > One idea is to rename the type to something else.  We could keep "char"
> > as an alias for backwards compatibility, but use the new name in system
> > catalogs, and document it as the main name of the type.
> 
> We don't have type aliases...

I meant the conversion we do from a certain name (say because it's the
SQL-mandated name for the type) to the internal name, such as mapping
integer to int4.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Re: Couple document fixes

Tom Lane <tgl@sss.pgh.pa.us> — 2011-03-11T16:01:06Z

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Excerpts from Tom Lane's message of vie mar 11 12:40:50 -0300 2011:
>> Alvaro Herrera <alvherre@commandprompt.com> writes:
>>> One idea is to rename the type to something else.  We could keep "char"
>>> as an alias for backwards compatibility, but use the new name in system
>>> catalogs, and document it as the main name of the type.

>> We don't have type aliases...

> I meant the conversion we do from a certain name (say because it's the
> SQL-mandated name for the type) to the internal name, such as mapping
> integer to int4.

That works for keywords.  "char" is, by definition, not a keyword.

			regards, tom lane

Re: Couple document fixes

Alvaro Herrera <alvherre@commandprompt.com> — 2011-03-11T16:08:36Z

Excerpts from Tom Lane's message of vie mar 11 13:01:06 -0300 2011:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Excerpts from Tom Lane's message of vie mar 11 12:40:50 -0300 2011:
> >> Alvaro Herrera <alvherre@commandprompt.com> writes:
> >>> One idea is to rename the type to something else.  We could keep "char"
> >>> as an alias for backwards compatibility, but use the new name in system
> >>> catalogs, and document it as the main name of the type.
> 
> >> We don't have type aliases...
> 
> > I meant the conversion we do from a certain name (say because it's the
> > SQL-mandated name for the type) to the internal name, such as mapping
> > integer to int4.
> 
> That works for keywords.  "char" is, by definition, not a keyword.

Oh.  Right, of course.

Seems the only option is to continue living with it.

(Well actually the other option would be to rename it and break
backwards compatibility.  I'm not sure anyone is going to be happy with
that though.)

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Re: Couple document fixes

Bruce Momjian <bruce@momjian.us> — 2011-09-05T18:21:46Z

Alvaro Herrera wrote:
> Removing CC to pg-docs so that Robert reads it.
> 
> Excerpts from Bruce Momjian's message of vie mar 11 08:13:20 -0300 2011:
> > Kevin Grittner wrote:
> 
> > > relpersistence should be <type>"char"</type>, not <type>char</type>.
> > > Oddly enough, there is a difference.
> > 
> > I am unsure on that one.  We have many 'char' mentions in catalog.sgml,
> > and I don't see any of them shown as '"char"'.  (Wow, we should have
> > just called this type char1, but I think that name came from Berkeley!) 
> > The big problem is that the pg_type name is really "char" _without_
> > quotes.
> 
> One idea is to rename the type to something else.  We could keep "char"
> as an alias for backwards compatibility, but use the new name in system
> catalogs, and document it as the main name of the type.
> 
> Discussed the idea a bit on IM with Bruce, but couldn't find any really
> good alternative.  Idea floated so far:
> 
> * byte (seems pretty decent to me)
> * octet (though maybe people would expect it'd output as a number)
> * char1 (looks ugly, but then we have int4 and so on)
> * achar (this one is just plain weird)
> 
> None seems great.  Thoughts?

Any new ideas on how to document our "char" data type?

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

Re: Couple document fixes

Alvaro Herrera <alvherre@commandprompt.com> — 2011-09-05T18:36:21Z

Excerpts from Bruce Momjian's message of lun sep 05 15:21:46 -0300 2011:
> Alvaro Herrera wrote:

> > Discussed the idea a bit on IM with Bruce, but couldn't find any really
> > good alternative.  Idea floated so far:
> > 
> > * byte (seems pretty decent to me)
> > * octet (though maybe people would expect it'd output as a number)
> > * char1 (looks ugly, but then we have int4 and so on)
> > * achar (this one is just plain weird)
> > 
> > None seems great.  Thoughts?
> 
> Any new ideas on how to document our "char" data type?

I think part of the problem is that this only seems to bother patch
developers, and only until they become aware of the issue.  After that,
it just becomes a known gotcha that's easy to work around.  Thus,
there's not much interest in spending a lot of time fixing it.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Re: Couple document fixes

David Fetter <david@fetter.org> — 2011-09-05T23:29:16Z

On Mon, Sep 05, 2011 at 02:21:46PM -0400, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Removing CC to pg-docs so that Robert reads it.
> > 
> > Excerpts from Bruce Momjian's message of vie mar 11 08:13:20 -0300 2011:
> > > Kevin Grittner wrote:
> > 
> > > > relpersistence should be <type>"char"</type>, not
> > > > <type>char</type>.  Oddly enough, there is a difference.
> > > 
> > > I am unsure on that one.  We have many 'char' mentions in
> > > catalog.sgml, and I don't see any of them shown as '"char"'.
> > > (Wow, we should have just called this type char1, but I think
> > > that name came from Berkeley!) The big problem is that the
> > > pg_type name is really "char" _without_ quotes.
> > 
> > One idea is to rename the type to something else.  We could keep
> > "char" as an alias for backwards compatibility, but use the new
> > name in system catalogs, and document it as the main name of the
> > type.
> > 
> > Discussed the idea a bit on IM with Bruce, but couldn't find any
> > really good alternative.  Idea floated so far:
> > 
> > * byte (seems pretty decent to me) * octet (though maybe people
> > would expect it'd output as a number) * char1 (looks ugly, but
> > then we have int4 and so on) * achar (this one is just plain
> > weird)
> > 
> > None seems great.  Thoughts?
> 
> Any new ideas on how to document our "char" data type?

What say we document it as deprecated and remove the silly thing over
the next three releases or so?  It's deep in the realm of
micro-optimization, and of a kind we well and truly don't need any
more, assuming we ever did.

Alternate proposals would involve a more aggressive deprecation and
removal schedule. ;)

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Re: Couple document fixes

Bruce Momjian <bruce@momjian.us> — 2011-09-05T23:33:09Z

David Fetter wrote:
> > > > I am unsure on that one.  We have many 'char' mentions in
> > > > catalog.sgml, and I don't see any of them shown as '"char"'.
> > > > (Wow, we should have just called this type char1, but I think
> > > > that name came from Berkeley!) The big problem is that the
> > > > pg_type name is really "char" _without_ quotes.
> > > 
> > > One idea is to rename the type to something else.  We could keep
> > > "char" as an alias for backwards compatibility, but use the new
> > > name in system catalogs, and document it as the main name of the
> > > type.
> > > 
> > > Discussed the idea a bit on IM with Bruce, but couldn't find any
> > > really good alternative.  Idea floated so far:
> > > 
> > > * byte (seems pretty decent to me) * octet (though maybe people
> > > would expect it'd output as a number) * char1 (looks ugly, but
> > > then we have int4 and so on) * achar (this one is just plain
> > > weird)
> > > 
> > > None seems great.  Thoughts?
> > 
> > Any new ideas on how to document our "char" data type?
> 
> What say we document it as deprecated and remove the silly thing over
> the next three releases or so?  It's deep in the realm of
> micro-optimization, and of a kind we well and truly don't need any
> more, assuming we ever did.
> 
> Alternate proposals would involve a more aggressive deprecation and
> removal schedule. ;)

Uh, pg_class uses it:

 relpersistence | "char"    | not null
 relkind        | "char"    | not null

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

Re: Couple document fixes

David Fetter <david@fetter.org> — 2011-09-06T00:05:10Z

On Mon, Sep 05, 2011 at 07:33:09PM -0400, Bruce Momjian wrote:
> David Fetter wrote:
> > > > > I am unsure on that one.  We have many 'char' mentions in
> > > > > catalog.sgml, and I don't see any of them shown as '"char"'.
> > > > > (Wow, we should have just called this type char1, but I think
> > > > > that name came from Berkeley!) The big problem is that the
> > > > > pg_type name is really "char" _without_ quotes.
> > > > 
> > > > One idea is to rename the type to something else.  We could keep
> > > > "char" as an alias for backwards compatibility, but use the new
> > > > name in system catalogs, and document it as the main name of the
> > > > type.
> > > > 
> > > > Discussed the idea a bit on IM with Bruce, but couldn't find any
> > > > really good alternative.  Idea floated so far:
> > > > 
> > > > * byte (seems pretty decent to me) * octet (though maybe people
> > > > would expect it'd output as a number) * char1 (looks ugly, but
> > > > then we have int4 and so on) * achar (this one is just plain
> > > > weird)
> > > > 
> > > > None seems great.  Thoughts?
> > > 
> > > Any new ideas on how to document our "char" data type?
> > 
> > What say we document it as deprecated and remove the silly thing over
> > the next three releases or so?  It's deep in the realm of
> > micro-optimization, and of a kind we well and truly don't need any
> > more, assuming we ever did.
> > 
> > Alternate proposals would involve a more aggressive deprecation and
> > removal schedule. ;)
> 
> Uh, pg_class uses it:
> 
>  relpersistence | "char"    | not null
>  relkind        | "char"    | not null
> 

Interesting. :)

Now that you mention it...

SELECT
    table_schema, table_name, column_name
FROM
    information_schema.columns
WHERE
    data_type = '"char"';
 table_schema |   table_name   |  column_name  
--------------+----------------+---------------
 pg_catalog   | pg_proc        | provolatile
 pg_catalog   | pg_type        | typtype
 pg_catalog   | pg_type        | typcategory
 pg_catalog   | pg_type        | typdelim
 pg_catalog   | pg_type        | typalign
 pg_catalog   | pg_type        | typstorage
 pg_catalog   | pg_attribute   | attstorage
 pg_catalog   | pg_attribute   | attalign
 pg_catalog   | pg_class       | relkind
 pg_catalog   | pg_constraint  | contype
 pg_catalog   | pg_constraint  | confupdtype
 pg_catalog   | pg_constraint  | confdeltype
 pg_catalog   | pg_constraint  | confmatchtype
 pg_catalog   | pg_operator    | oprkind
 pg_catalog   | pg_rewrite     | ev_type
 pg_catalog   | pg_rewrite     | ev_enabled
 pg_catalog   | pg_trigger     | tgenabled
 pg_catalog   | pg_cast        | castcontext
 pg_catalog   | pg_cast        | castmethod
 pg_catalog   | pg_depend      | deptype
 pg_catalog   | pg_shdepend    | deptype
 pg_catalog   | pg_default_acl | defaclobjtype
(22 rows)

On brief inspection, it appears that each of these would be better
served, at least functionally, with some kind of enumerated type.
Might it be worth trying to micro-optimize this case for a one-byte
enum?  Or maybe something like the varvarlena pattern?

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Re: Couple document fixes

Alvaro Herrera <alvherre@commandprompt.com> — 2011-09-06T01:07:29Z

Excerpts from David Fetter's message of lun sep 05 21:05:10 -0300 2011:

> On brief inspection, it appears that each of these would be better
> served, at least functionally, with some kind of enumerated type.
> Might it be worth trying to micro-optimize this case for a one-byte
> enum?  Or maybe something like the varvarlena pattern?

What would be the point?  It works pretty well already.  It doesn't need
fixing.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Re: Couple document fixes

David Fetter <david@fetter.org> — 2011-09-06T04:22:18Z

On Mon, Sep 05, 2011 at 10:07:29PM -0300, Alvaro Herrera wrote:
> Excerpts from David Fetter's message of lun sep 05 21:05:10 -0300 2011:
> 
> > On brief inspection, it appears that each of these would be better
> > served, at least functionally, with some kind of enumerated type.
> > Might it be worth trying to micro-optimize this case for a one-byte
> > enum?  Or maybe something like the varvarlena pattern?
> 
> What would be the point?

Removing the legacy "char" type, per original post. :)

> It works pretty well already.  It doesn't need fixing.

We've made changes as big on aesthetic grounds before, and if the
change results in an enum type optimized for space efficiency, that's
all to the good.

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Re: Couple document fixes

Tom Lane <tgl@sss.pgh.pa.us> — 2011-09-06T15:19:45Z

David Fetter <david@fetter.org> writes:
> On Mon, Sep 05, 2011 at 10:07:29PM -0300, Alvaro Herrera wrote:
>> What would be the point?

> Removing the legacy "char" type, per original post. :)

Removing it is the wrong solution.

The idea of renaming it to char1 might be an appropriate balance of pain
versus benefit.  Or perhaps not; I'd want to see a proposed patch before
committing to doing anything here.

> We've made changes as big on aesthetic grounds before, and if the
> change results in an enum type optimized for space efficiency, that's
> all to the good.

That's a pipe dream.  You can't use enums in catalogs that underlie the
enum implementation.  Possibly you could kluge something so that there
are phony entries in pg_enum reflecting the hard-wired values that the C
code uses, but I entirely fail to see any point in such a thing.

			regards, tom lane