1996-08-27 23:50:29 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* tupdesc.h
|
1997-09-07 07:04:48 +02:00
|
|
|
* POSTGRES tuple descriptor definitions.
|
1996-08-27 23:50:29 +02:00
|
|
|
*
|
|
|
|
|
*
|
2020-01-01 18:21:45 +01:00
|
|
|
* Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-08-27 23:50:29 +02:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/access/tupdesc.h
|
1996-08-27 23:50:29 +02:00
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
#ifndef TUPDESC_H
|
1996-08-27 23:50:29 +02:00
|
|
|
#define TUPDESC_H
|
|
|
|
|
|
1999-07-16 01:04:24 +02:00
|
|
|
#include "access/attnum.h"
|
|
|
|
|
#include "catalog/pg_attribute.h"
|
1999-07-16 19:07:40 +02:00
|
|
|
#include "nodes/pg_list.h"
|
1996-08-27 23:50:29 +02:00
|
|
|
|
1997-08-19 06:46:15 +02:00
|
|
|
|
2019-01-15 01:15:20 +01:00
|
|
|
typedef struct AttrDefault
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
AttrNumber adnum;
|
1999-10-04 01:55:40 +02:00
|
|
|
char *adbin; /* nodeToString representation of expr */
|
1997-09-08 22:59:27 +02:00
|
|
|
} AttrDefault;
|
1997-08-21 06:10:25 +02:00
|
|
|
|
2019-01-15 01:15:20 +01:00
|
|
|
typedef struct ConstrCheck
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
char *ccname;
|
1999-10-04 01:55:40 +02:00
|
|
|
char *ccbin; /* nodeToString representation of expr */
|
2011-06-02 00:43:50 +02:00
|
|
|
bool ccvalid;
|
2012-04-21 04:46:20 +02:00
|
|
|
bool ccnoinherit; /* this is a non-inheritable constraint */
|
1997-09-08 23:56:23 +02:00
|
|
|
} ConstrCheck;
|
1997-08-21 06:10:25 +02:00
|
|
|
|
|
|
|
|
/* This structure contains constraints of a tuple */
|
2019-01-15 01:15:20 +01:00
|
|
|
typedef struct TupleConstr
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1999-10-04 01:55:40 +02:00
|
|
|
AttrDefault *defval; /* array */
|
|
|
|
|
ConstrCheck *check; /* array */
|
2019-05-22 18:55:34 +02:00
|
|
|
struct AttrMissing *missing; /* missing attributes values, NULL if none */
|
1997-09-08 04:41:22 +02:00
|
|
|
uint16 num_defval;
|
|
|
|
|
uint16 num_check;
|
|
|
|
|
bool has_not_null;
|
2019-03-30 08:13:09 +01:00
|
|
|
bool has_generated_stored;
|
1997-09-08 23:56:23 +02:00
|
|
|
} TupleConstr;
|
1997-08-21 06:10:25 +02:00
|
|
|
|
|
|
|
|
/*
|
2005-03-07 05:42:17 +01:00
|
|
|
* This struct is passed around within the backend to describe the structure
|
|
|
|
|
* of tuples. For tuples coming from on-disk relations, the information is
|
|
|
|
|
* collected from the pg_attribute, pg_attrdef, and pg_constraint catalogs.
|
|
|
|
|
* Transient row types (such as the result of a join query) have anonymous
|
|
|
|
|
* TupleDesc structs that generally omit any constraint info; therefore the
|
|
|
|
|
* structure is designed to let the constraints be omitted efficiently.
|
2004-04-01 23:28:47 +02:00
|
|
|
*
|
|
|
|
|
* Note that only user attributes, not system attributes, are mentioned in
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
* TupleDesc.
|
2004-04-01 23:28:47 +02:00
|
|
|
*
|
2005-03-07 05:42:17 +01:00
|
|
|
* If the tupdesc is known to correspond to a named rowtype (such as a table's
|
2014-05-06 18:12:18 +02:00
|
|
|
* rowtype) then tdtypeid identifies that type and tdtypmod is -1. Otherwise
|
2004-04-01 23:28:47 +02:00
|
|
|
* tdtypeid is RECORDOID, and tdtypmod can be either -1 for a fully anonymous
|
|
|
|
|
* row type, or a value >= 0 to allow the rowtype to be looked up in the
|
|
|
|
|
* typcache.c type cache.
|
2006-06-16 20:42:24 +02:00
|
|
|
*
|
2017-10-26 19:47:45 +02:00
|
|
|
* Note that tdtypeid is never the OID of a domain over composite, even if
|
|
|
|
|
* we are dealing with values that are known (at some higher level) to be of
|
|
|
|
|
* a domain-over-composite type. This is because tdtypeid/tdtypmod need to
|
|
|
|
|
* match up with the type labeling of composite Datums, and those are never
|
|
|
|
|
* explicitly marked as being of a domain type, either.
|
|
|
|
|
*
|
2006-06-16 20:42:24 +02:00
|
|
|
* Tuple descriptors that live in caches (relcache or typcache, at present)
|
|
|
|
|
* are reference-counted: they can be deleted when their reference count goes
|
|
|
|
|
* to zero. Tuple descriptors created by the executor need no reference
|
|
|
|
|
* counting, however: they are simply created in the appropriate memory
|
|
|
|
|
* context and go away when the context is freed. We set the tdrefcount
|
|
|
|
|
* field of such a descriptor to -1, while reference-counted descriptors
|
|
|
|
|
* always have tdrefcount >= 0.
|
1997-08-21 06:10:25 +02:00
|
|
|
*/
|
2019-01-15 01:15:20 +01:00
|
|
|
typedef struct TupleDescData
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2005-03-07 05:42:17 +01:00
|
|
|
int natts; /* number of attributes in the tuple */
|
2004-04-01 23:28:47 +02:00
|
|
|
Oid tdtypeid; /* composite type ID for tuple type */
|
|
|
|
|
int32 tdtypmod; /* typmod for tuple type */
|
2006-06-16 20:42:24 +02:00
|
|
|
int tdrefcount; /* reference count, or -1 if not counting */
|
2017-08-20 20:19:12 +02:00
|
|
|
TupleConstr *constr; /* constraints, or NULL if none */
|
|
|
|
|
/* attrs[N] is the description of Attribute Number N+1 */
|
|
|
|
|
FormData_pg_attribute attrs[FLEXIBLE_ARRAY_MEMBER];
|
2019-05-22 18:55:34 +02:00
|
|
|
} TupleDescData;
|
2019-01-15 01:15:20 +01:00
|
|
|
typedef struct TupleDescData *TupleDesc;
|
1996-08-27 23:50:29 +02:00
|
|
|
|
2017-08-20 20:19:07 +02:00
|
|
|
/* Accessor for the i'th attribute of tupdesc. */
|
2017-08-20 20:19:12 +02:00
|
|
|
#define TupleDescAttr(tupdesc, i) (&(tupdesc)->attrs[(i)])
|
2002-07-20 07:16:59 +02:00
|
|
|
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
extern TupleDesc CreateTemplateTupleDesc(int natts);
|
2002-07-20 07:16:59 +02:00
|
|
|
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
extern TupleDesc CreateTupleDesc(int natts, Form_pg_attribute *attrs);
|
1996-08-27 23:50:29 +02:00
|
|
|
|
|
|
|
|
extern TupleDesc CreateTupleDescCopy(TupleDesc tupdesc);
|
|
|
|
|
|
1997-08-22 05:55:39 +02:00
|
|
|
extern TupleDesc CreateTupleDescCopyConstr(TupleDesc tupdesc);
|
|
|
|
|
|
2017-09-15 04:59:21 +02:00
|
|
|
#define TupleDescSize(src) \
|
2019-01-15 01:15:20 +01:00
|
|
|
(offsetof(struct TupleDescData, attrs) + \
|
2017-09-15 04:59:21 +02:00
|
|
|
(src)->natts * sizeof(FormData_pg_attribute))
|
|
|
|
|
|
|
|
|
|
extern void TupleDescCopy(TupleDesc dst, TupleDesc src);
|
|
|
|
|
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
extern void TupleDescCopyEntry(TupleDesc dst, AttrNumber dstAttno,
|
2019-05-22 19:04:48 +02:00
|
|
|
TupleDesc src, AttrNumber srcAttno);
|
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry. The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others. This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does. There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST(). After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me
2013-11-22 01:37:02 +01:00
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
extern void FreeTupleDesc(TupleDesc tupdesc);
|
1997-08-22 05:55:39 +02:00
|
|
|
|
2006-06-16 20:42:24 +02:00
|
|
|
extern void IncrTupleDescRefCount(TupleDesc tupdesc);
|
|
|
|
|
extern void DecrTupleDescRefCount(TupleDesc tupdesc);
|
|
|
|
|
|
|
|
|
|
#define PinTupleDesc(tupdesc) \
|
|
|
|
|
do { \
|
|
|
|
|
if ((tupdesc)->tdrefcount >= 0) \
|
|
|
|
|
IncrTupleDescRefCount(tupdesc); \
|
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
|
|
#define ReleaseTupleDesc(tupdesc) \
|
|
|
|
|
do { \
|
|
|
|
|
if ((tupdesc)->tdrefcount >= 0) \
|
|
|
|
|
DecrTupleDescRefCount(tupdesc); \
|
|
|
|
|
} while (0)
|
2006-10-04 02:30:14 +02:00
|
|
|
|
2000-01-31 05:35:57 +01:00
|
|
|
extern bool equalTupleDescs(TupleDesc tupdesc1, TupleDesc tupdesc2);
|
|
|
|
|
|
2017-08-23 01:05:48 +02:00
|
|
|
extern uint32 hashTupleDesc(TupleDesc tupdesc);
|
|
|
|
|
|
2002-03-29 20:06:29 +01:00
|
|
|
extern void TupleDescInitEntry(TupleDesc desc,
|
2019-05-22 19:04:48 +02:00
|
|
|
AttrNumber attributeNumber,
|
|
|
|
|
const char *attributeName,
|
|
|
|
|
Oid oidtypeid,
|
|
|
|
|
int32 typmod,
|
|
|
|
|
int attdim);
|
1996-08-27 23:50:29 +02:00
|
|
|
|
2017-01-24 22:59:18 +01:00
|
|
|
extern void TupleDescInitBuiltinEntry(TupleDesc desc,
|
2019-05-22 19:04:48 +02:00
|
|
|
AttrNumber attributeNumber,
|
|
|
|
|
const char *attributeName,
|
|
|
|
|
Oid oidtypeid,
|
|
|
|
|
int32 typmod,
|
|
|
|
|
int attdim);
|
2017-01-24 22:59:18 +01:00
|
|
|
|
2011-02-08 22:04:18 +01:00
|
|
|
extern void TupleDescInitEntryCollation(TupleDesc desc,
|
2019-05-22 19:04:48 +02:00
|
|
|
AttrNumber attributeNumber,
|
|
|
|
|
Oid collationid);
|
2011-02-08 22:04:18 +01:00
|
|
|
|
2002-03-29 20:06:29 +01:00
|
|
|
extern TupleDesc BuildDescForRelation(List *schema);
|
2001-10-28 07:26:15 +01:00
|
|
|
|
2011-02-08 22:04:18 +01:00
|
|
|
extern TupleDesc BuildDescFromLists(List *names, List *types, List *typmods, List *collations);
|
2006-03-16 01:31:55 +01:00
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* TUPDESC_H */
|
