Move catalog toast table and index declarations

On Thu, Oct 22, 2020 at 6:21 AM Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> wrote:

[v1]

Hi Peter,

This part created a syntax error:

--- a/src/include/catalog/unused_oids
+++ b/src/include/catalog/unused_oids
@@ -28,7 +28,7 @@ chdir $FindBin::RealBin or die "could not cd to
$FindBin::RealBin: $!\n";
 use lib "$FindBin::RealBin/../../backend/catalog/";
 use Catalog;

-my @input_files = (glob("pg_*.h"), qw(indexing.h));
+my @input_files = (glob("pg_*.h");

Style: In genbki.h, "extern int no_such_variable" is now out of place.
Also, the old comments like "The macro definitions are just to keep the C
compiler from spitting up." are now redundant in their new setting.

The rest looks good to me. unused_oids (once fixed), duplicate_oids, and
renumber_oids.pl seem to work fine.

--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 2020-10-24 15:23, John Naylor wrote:

This part created a syntax error:

--- a/src/include/catalog/unused_oids
+++ b/src/include/catalog/unused_oids
@@ -28,7 +28,7 @@ chdir $FindBin::RealBin or die "could not cd to 
$FindBin::RealBin: $!\n";
 use lib "$FindBin::RealBin/../../backend/catalog/";
 use Catalog;

-my @input_files = (glob("pg_*.h"), qw(indexing.h));
+my @input_files = (glob("pg_*.h");

OK, fixing that.

Style: In genbki.h, "extern int no_such_variable" is now out of place.
Also, the old comments like "The macro definitions are just to keep the
C compiler from spitting up." are now redundant in their new setting.

Hmm, I don't really see what's wrong there. Do you mean the macro
definitions should be different, or the comments are wrong, or something
else?

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Tue, Oct 27, 2020 at 7:43 AM Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> wrote:

On 2020-10-24 15:23, John Naylor wrote:

Style: In genbki.h, "extern int no_such_variable" is now out of place.
Also, the old comments like "The macro definitions are just to keep the
C compiler from spitting up." are now redundant in their new setting.

Hmm, I don't really see what's wrong there. Do you mean the macro
definitions should be different, or the comments are wrong, or something
else?

There's nothing wrong; it's just a minor point of consistency. For the
first part, I mean defined symbols in this file that are invisible to the C
compiler are written

#define SOMETHING()

If some are written

#define SOMETHING() extern int no_such_variable

I imagine some future reader will wonder why there's a difference.

As for the comments, the entire file is for things meant for scripts to
read, but have to be put in macro form to be invisible to the compiler. The
header comment has

"genbki.h defines CATALOG(), BKI_BOOTSTRAP and related macros
* so that the catalog header files can be read by the C compiler."

I'm just saying we don't need to carry over the comments I mentioned from
the toasting/indexing headers that were specially for those macros.

--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 2020-10-27 13:12, John Naylor wrote:

There's nothing wrong; it's just a minor point of consistency. For the
first part, I mean defined symbols in this file that are invisible to
the C compiler are written

#define SOMETHING()

If some are written

#define SOMETHING() extern int no_such_variable

I imagine some future reader will wonder why there's a difference.

The difference is that CATALOG() is followed in actual use by something like

{ ... } FormData_pg_attribute;

so it becomes a valid C statement. For DECLARE_INDEX() etc., we need to
do something else to make it valid. I guess this could be explained in
more detail (as I'm attempting in this email), but this isn't materially
changed by this patch.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Thu, Nov 5, 2020 at 4:24 AM Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> wrote:

On 2020-10-27 13:12, John Naylor wrote:

There's nothing wrong; it's just a minor point of consistency. For the
first part, I mean defined symbols in this file that are invisible to
the C compiler are written

#define SOMETHING()

If some are written

#define SOMETHING() extern int no_such_variable

I imagine some future reader will wonder why there's a difference.

The difference is that CATALOG() is followed in actual use by something
like

{ ... } FormData_pg_attribute;

so it becomes a valid C statement. For DECLARE_INDEX() etc., we need to
do something else to make it valid. I guess this could be explained in
more detail (as I'm attempting in this email), but this isn't materially
changed by this patch.

I think we're talking past eachother. Here's a concrete example:

#define BKI_ROWTYPE_OID(oid,oidmacro)
#define DECLARE_TOAST(name,toastoid,indexoid) extern int no_such_variable

I understand these to be functionally equivalent as far as what the C
compiler sees. If not, I'd be curious to know what the difference is. I was
thinking this is just a random style difference, and if so, they should be
the same now that they're in the same file together:

#define BKI_ROWTYPE_OID(oid,oidmacro)
#define DECLARE_TOAST(name,toastoid,indexoid)

And yes, this doesn't materially change the patch, it's just nitpicking :-)
. Materially, I believe it's fine.

--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 2020-11-05 12:59, John Naylor wrote:

I think we're talking past eachother. Here's a concrete example:

#define BKI_ROWTYPE_OID(oid,oidmacro)
#define DECLARE_TOAST(name,toastoid,indexoid) extern int no_such_variable

I understand these to be functionally equivalent as far as what the C
compiler sees.

The issue is that you can't have a bare semicolon at the top level of a
C compilation unit, at least on some compilers. So doing

#define FOO(stuff) /*empty*/

and then

FOO(123);

won't work. You need to fill the definition of FOO with some stuff to
make it valid.

BKI_ROWTYPE_OID on the other hand is not used at the top level like
this, so it can be defined to empty.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Thu, Nov 5, 2020 at 2:20 PM Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> wrote:

On 2020-11-05 12:59, John Naylor wrote:

I think we're talking past eachother. Here's a concrete example:

#define BKI_ROWTYPE_OID(oid,oidmacro)
#define DECLARE_TOAST(name,toastoid,indexoid) extern int no_such_variable

I understand these to be functionally equivalent as far as what the C
compiler sees.

The issue is that you can't have a bare semicolon at the top level of a
C compilation unit, at least on some compilers. So doing

#define FOO(stuff) /*empty*/

and then

FOO(123);

won't work. You need to fill the definition of FOO with some stuff to
make it valid.

BKI_ROWTYPE_OID on the other hand is not used at the top level like
this, so it can be defined to empty.

Thank you for the explanation.

--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 2020-11-05 12:59, John Naylor wrote:

And yes, this doesn't materially change the patch, it's just nitpicking
:-) . Materially, I believe it's fine.

OK, committed.

--
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/