Re: An inconsistency in the documentation about full text search

2023-11-29 Thread Euler Taveira
On Tue, Nov 7, 2023, at 7:12 AM, Erki Eessaar wrote: > Section > > 12.2.2. Creating Indexes > https://www.postgresql.org/docs/current/textsearch-tables.html#TEXTSEARCH-TABLES-INDEX > > wrtites the following: "Another approach is to create a separate tsvector > column to hold the output of

Re: "name" vs "alias" in datatype table

2023-11-29 Thread Eric Hanson
On Wed, Nov 29, 2023 at 10:26 AM Tom Lane wrote: > I could see splitting this into three columns: > > 1. Preferred name (the standard's name, if it's a standard type) > > 2. Internal name (pg_type.typname), perhaps only if different from #1 > > 3. Other aliases > I like the preferred name being

Re: "name" vs "alias" in datatype table

2023-11-29 Thread Alvaro Herrera
On 2023-Nov-29, Tom Lane wrote: > Eric Hanson writes: > > The larger point being, the "name" vs "alias" paradigm presented in this > > table does not accurately represent PostgreSQL, and conveys an inaccurate > > picture of the relationship between type names. int4 is not an "alias". > > I

Re: "name" vs "alias" in datatype table

2023-11-29 Thread Tom Lane
Eric Hanson writes: > The larger point being, the "name" vs "alias" paradigm presented in this > table does not accurately represent PostgreSQL, and conveys an inaccurate > picture of the relationship between type names. int4 is not an "alias". I agree that this could be improved, mainly

Re: Clarification regarding CREATE TABLE LIKE and FOREIGN KEYS

2023-11-29 Thread Euler Taveira
On Mon, Nov 27, 2023, at 12:05 PM, PG Doc comments form wrote: > It is not clear to me that foreign keys are copied or not when duplicating a > table using CREATE TABLE ... LIKE ... INCLUDING ALL. I had to actually test > to check what it does. > It is impractical to add what a feature *does

Re: "name" vs "alias" in datatype table

2023-11-29 Thread Eric Hanson
The larger point being, the "name" vs "alias" paradigm presented in this table does not accurately represent PostgreSQL, and conveys an inaccurate picture of the relationship between type names. int4 is not an "alias". On Wed, Nov 29, 2023 at 8:10 AM Eric Hanson wrote: > On Wed, Nov 29, 2023

Re: "name" vs "alias" in datatype table

2023-11-29 Thread Eric Hanson
On Wed, Nov 29, 2023 at 7:40 AM Peter Eisentraut wrote: > On 23.11.23 21:51, PG Doc comments form wrote: > > I think there could be some clarification of what is a "name" vs. > "alias" on > > the datatypes table. Right now, what's in the "Aliases" column is > sometimes > > postgres's internal

Re: INFORMATION_SCHEMA.routine_column_usage

2023-11-29 Thread Peter Eisentraut
Here https://www.postgresql.org/docs/current/infoschema-routine-column-usage.html it is stated that "The view |routine_column_usage| is meant to identify all columns that are used by a function or procedure. This

Re: "name" vs "alias" in datatype table

2023-11-29 Thread Peter Eisentraut
On 23.11.23 21:51, PG Doc comments form wrote: I think there could be some clarification of what is a "name" vs. "alias" on the datatypes table. Right now, what's in the "Aliases" column is sometimes postgres's internal type (e.g. `pg_catalog.int4`), and sometimes the "pretty name", (e.g.