aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor
Commit message (Collapse)AuthorAge
...
* Make a couple of small changes to the tuplestore API, for the benefit of theTom Lane2008-12-27
| | | | | | | | | | | | upcoming window-functions patch. First, tuplestore_trim is now an exported function that must be explicitly invoked by callers at appropriate times, rather than something that tuplestore tries to do behind the scenes. Second, a read pointer that is marked as allowing backward scan no longer prevents truncation. This means that a read pointer marked as having BACKWARD but not REWIND capability can only safely read backwards as far as the oldest other read pointer. (The expected use pattern for this involves having another read pointer that serves as the truncation fencepost.)
* Fix oversight in my recent patch to allow ExecMakeFunctionResult to handleTom Lane2008-12-18
| | | | | | | materialize-mode set results. Since it now uses the ReturnSetInfo node to hold internal state, we need to be sure to set up the node even when the immediately called function doesn't return set (but does have a set-valued argument). Per report from Anupama Aherrao.
* Remove pg_plan_queries()'s now-useless needSnapshot parameter. It's uselessTom Lane2008-12-13
| | | | | in 8.3, too, but I'm not back-patching this change since it would break any extension modules that might be calling that function.
* Ensure that the contents of a holdable cursor don't depend on out-of-lineTom Lane2008-12-01
| | | | | | | | | | | toasted values, since those could get dropped once the cursor's transaction is over. Per bug #4553 from Andrew Gierth. Back-patch as far as 8.1. The bug actually exists back to 7.4 when holdable cursors were introduced, but this patch won't work before 8.1 without significant adjustments. Given the lack of field complaints, it doesn't seem worth the work (and risk of introducing new bugs) to try to make a patch for the older branches.
* Clean up the API for DestReceiver objects by eliminating the assumptionTom Lane2008-11-30
| | | | | | | | | | | | that a Portal is a useful and sufficient additional argument for CreateDestReceiver --- it just isn't, in most cases. Instead formalize the approach of passing any needed parameters to the receiver separately. One unexpected benefit of this change is that we can declare typedef Portal in a less surprising location. This patch is just code rearrangement and doesn't change any functionality. I'll tackle the HOLD-cursor-vs-toast problem in a follow-on patch.
* Fix minor memory leak introduced in recent SQL-functions hacking: theTom Lane2008-11-27
| | | | | | DestReceiver created during postquel_start needs to be destroyed during postquel_end. In a moment of brain fade I had assumed this would be taken care of by FreeQueryDesc, but it's not (and shouldn't be).
* Some infrastructure changes for the upcoming auto-explain contrib module:Tom Lane2008-11-19
| | | | | | | | | | | | | | | | | | | | | | * Refactor explain.c slightly to export a convenient-to-use subroutine for printing EXPLAIN results. * Provide hooks for plugins to get control at ExecutorStart and ExecutorEnd as well as ExecutorRun. * Add some minimal support for tracking the total runtime of ExecutorRun. This code won't actually do anything unless a plugin prods it to. * Change the API of the DefineCustomXXXVariable functions to allow nonzero "flags" to be specified for a custom GUC variable. While at it, also make the "bootstrap" default value for custom GUCs be explicitly specified as a parameter to these functions. This is to eliminate confusion over where the default comes from, as has been expressed in the past by some users of the custom-variable facility. * Refactor GUC code a bit to ensure that a custom variable gets initialized to something valid (like its default value) even if the placeholder value was invalid.
* Modify UPDATE/DELETE WHERE CURRENT OF to use the FOR UPDATE infrastructure toTom Lane2008-11-16
| | | | | | | locate the target row, if the cursor was declared with FOR UPDATE or FOR SHARE. This approach is more flexible and reliable than digging through the plan tree; for instance it can cope with join cursors. But we still provide the old code for use with non-FOR-UPDATE cursors. Per gripe from Robert Haas.
* Fix crash of xmlconcat(NULL)Peter Eisentraut2008-11-15
| | | | also backpatched to 8.3
* Make SELECT FOR UPDATE/SHARE work on inheritance trees, by having the planTom Lane2008-11-15
| | | | | | | | | return the tableoid as well as the ctid for any FOR UPDATE targets that have child tables. All child tables are listed in the ExecRowMark list, but the executor just skips the ones that didn't produce the current row. Curiously, this longstanding restriction doesn't seem to have been documented anywhere; so no doc changes.
* Improve bulk-insert performance by keeping the current target buffer pinnedTom Lane2008-11-06
| | | | | | | (but not locked, as that would risk deadlocks). Also, make it work in a small ring of buffers to avoid having bulk inserts trash the whole buffer arena. Robert Haas, after an idea of Simon Riggs'.
* Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple,Tom Lane2008-11-02
| | | | | | | | | | | and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
* Simplify ExecutorRun's API and save some trivial number of cycles by havingTom Lane2008-10-31
| | | | | | | it just return void instead of sometimes returning a TupleTableSlot. SQL functions don't need that anymore, and noplace else does either. Eliminating the return value also means one less hassle for the ExecutorRun hook functions that will be supported beginning in 8.4.
* Allow SQL-language functions to return the output of an INSERT/UPDATE/DELETETom Lane2008-10-31
| | | | | | | | | RETURNING clause, not just a SELECT as formerly. A side effect of this patch is that when a set-returning SQL function is used in a FROM clause, performance is improved because the output is collected into a tuplestore within the function, rather than using the less efficient value-per-call mechanism.
* Be more tense about not creating tuplestores with randomAccess = true unlessTom Lane2008-10-29
| | | | | | | | backwards scan could actually happen. In particular, pass a flag to materialize-mode SRFs that tells them whether they need to require random access. In passing, also suppress unneeded backward-scan overhead for a Portal's holdStore tuplestore. Per my proposal about reducing I/O costs for tuplestores.
* Extend ExecMakeFunctionResult() to support set-returning functions that returnTom Lane2008-10-28
| | | | | | | | | via a tuplestore instead of value-per-call. Refactor a few things to reduce ensuing code duplication with nodeFunctionscan.c. This represents the reasonably noncontroversial part of my proposed patch to switch SQL functions over to returning tuplestores. For the moment, SQL functions still do things the old way. However, this change enables PL SRFs to be called in targetlists (observe changes in plperl regression results).
* Change WorkTableScan to not support backward scan. The apparent supportTom Lane2008-10-28
| | | | | | | | | | didn't actually work, because nodeRecursiveunion.c creates the underlying tuplestore with backward scan disabled; which is a decision that we shouldn't reverse because of performance cost. We could imagine adding signaling from WorkTableScan to RecursiveUnion about whether backward scan is needed ... but in practice it'd be a waste of effort, because there simply isn't any current or plausible future scenario where WorkTableScan would be called on to scan backward. So just dike out the code that claims to support it.
* Fix an oversight in two different recent patches: nodes that support SRFsTom Lane2008-10-23
| | | | | | in their targetlists had better reset ps_TupFromTlist during ReScan calls. There's no need to back-patch here since nodeAgg and nodeGroup didn't even pretend to support SRFs in prior releases.
* Remove useless ps_OuterTupleSlot field from PlanState. I suppose this wasTom Lane2008-10-23
| | | | | used long ago, but in the current code the ecxt_outertuple field of ExprContext is doing all the work. Spotted by Ran Tang.
* Add a new column to pg_am to specify whether an index AM supports backwardTom Lane2008-10-17
| | | | | | | | | | | | | | | | scanning; GiST and GIN do not, and it seems like too much trouble to make them do so. By teaching ExecSupportsBackwardScan() about this restriction, we ensure that the planner will protect a scroll cursor from the problem by adding a Materialize node. In passing, fix another longstanding bug in the same area: backwards scan of a plan with set-returning functions in the targetlist did not work either, since the TupFromTlist expansion code pays no attention to direction (and has no way to run a SRF backwards anyway). Again the fix is to make ExecSupportsBackwardScan check this restriction. Also adjust the index AM API specification to note that mark/restore support is unnecessary if the AM can't produce ordered output.
* Fix a small memory leak in ExecReScanAgg() in the hashed aggregation case.Neil Conway2008-10-16
| | | | | | | In the previous coding, the list of columns that needed to be hashed on was allocated in the per-query context, but we reallocated every time the Agg node was rescanned. Since this information doesn't change over a rescan, just construct the list of columns once during ExecInitAgg().
* Fix SPI_getvalue and SPI_getbinval to range-check the given attribute numberTom Lane2008-10-16
| | | | | | | | | | | | | | according to the TupleDesc's natts, not the number of physical columns in the tuple. The previous coding would do the wrong thing in cases where natts is different from the tuple's column count: either incorrectly report error when it should just treat the column as null, or actually crash due to indexing off the end of the TupleDesc's attribute array. (The second case is probably not possible in modern PG versions, due to more careful handling of inheritance cases than we once had. But it's still a clear lack of robustness here.) The incorrect error indication is ignored by all callers within the core PG distribution, so this bug has no symptoms visible within the core code, but it might well be an issue for add-on packages. So patch all the way back.
* Fix corner case wherein a WorkTableScan node could get initialized before theTom Lane2008-10-13
| | | | | | RecursiveUnion to which it refers. It turns out that we can just postpone the relevant initialization steps until the first exec call for the node, by which time the ancestor node must surely be initialized. Per report from Greg Stark.
* Extend CTE patch to support recursive UNION (ie, without ALL). TheTom Lane2008-10-07
| | | | | | implementation uses an in-memory hash table, so it will poop out for very large recursive results ... but the performance characteristics of a sort-based implementation would be pretty unpleasant too.
* Implement SQL-standard WITH clauses, including WITH RECURSIVE.Tom Lane2008-10-04
| | | | | | | | | | | | | There are some unimplemented aspects: recursive queries must use UNION ALL (should allow UNION too), and we don't have SEARCH or CYCLE clauses. These might or might not get done for 8.4, but even without them it's a pretty useful feature. There are also a couple of small loose ends and definitional quibbles, which I'll send a memo about to pgsql-hackers shortly. But let's land the patch now so we can get on with other development. Yoshiyuki Asaba, with lots of help from Tatsuo Ishii and Tom Lane
* Improve tuplestore.c to support multiple concurrent read positions.Tom Lane2008-10-01
| | | | | | | | | | | This facility replaces the former mark/restore support but is otherwise upward-compatible with previous uses. It's expected to be needed for single evaluation of CTEs and also for window functions, so I'm committing it separately instead of waiting for either one of those patches to be finished. Per discussion with Greg Stark and Hitoshi Harada. Note: I removed nodeFunctionscan's mark/restore support, instead of bothering to update it for this change, because it was dead code anyway.
* Fix caching of foreign-key-checking queries so that when a replan is needed,Tom Lane2008-09-15
| | | | | | | | we regenerate the SQL query text not merely the plan derived from it. This is needed to handle contingencies such as renaming of a table or column used in an FK. Pre-8.3, such cases worked despite the lack of replanning (because the cached plan needn't actually change), so this is a regression. Per bug #4417 from Benjamin Bihler.
* Initialize the minimum frozen Xid in vac_update_datfrozenxid usingAlvaro Herrera2008-09-11
| | | | | | | | | | | | | | | | | | | | GetOldestXmin() instead of RecentGlobalXmin; this is safer because we do not depend on the latter being correctly set elsewhere, and while it is more expensive, this code path is not performance-critical. This is a real risk for autovacuum, because it can execute whole cycles without doing a single vacuum, which would mean that RecentGlobalXmin would stay at its initialization value, FirstNormalTransactionId, causing a bogus value to be inserted in pg_database. This bug could explain some recent reports of failure to truncate pg_clog. At the same time, change the initialization of RecentGlobalXmin to InvalidTransactionId, and ensure that it's set to something else whenever it's going to be used. Using it as FirstNormalTransactionId in HOT page pruning could incur in data loss. InitPostgres takes care of setting it to a valid value, but the extra checks are there to prevent "special" backends from behaving in unusual ways. Per Tom Lane's detailed problem dissection in 29544.1221061979@sss.pgh.pa.us
* Support set-returning functions in the target lists of Agg and Group planTom Lane2008-09-08
| | | | | | nodes. This is a pretty ugly feature but since we don't yet have a plausible substitute, we'd better support it everywhere. Per gripe from Jeff Davis.
* Move exprType(), exprTypmod(), expression_tree_walker(), and related routinesTom Lane2008-08-25
| | | | | | into nodes/nodeFuncs, so as to reduce wanton cross-subsystem #includes inside the backend. There's probably more that should be done along this line, but this is a start anyway.
* Get rid of the last remaining uses of var_is_rel(), to wit some debuggingTom Lane2008-08-25
| | | | | | | | | checks in ExecIndexBuildScanKeys() that were inadequate anyway: it's better to verify the correct varno on an expected index key, not just reject OUTER and INNER. This makes the entire current contents of nodeFuncs.c dead code. I'll be replacing it with some other stuff later, as per recent proposal.
* Arrange to convert EXISTS subqueries that are equivalent to hashable INTom Lane2008-08-22
| | | | | | | | | | | | | | | | | | | | | | | subqueries into the same thing you'd have gotten from IN (except always with unknownEqFalse = true, so as to get the proper semantics for an EXISTS). I believe this fixes the last case within CVS HEAD in which an EXISTS could give worse performance than an equivalent IN subquery. The tricky part of this is that if the upper query probes the EXISTS for only a few rows, the hashing implementation can actually be worse than the default, and therefore we need to make a cost-based decision about which way to use. But at the time when the planner generates plans for subqueries, it doesn't really know how many times the subquery will be executed. The least invasive solution seems to be to generate both plans and postpone the choice until execution. Therefore, in a query that has been optimized this way, EXPLAIN will show two subplans for the EXISTS, of which only one will actually get executed. There is a lot more that could be done based on this infrastructure: in particular it's interesting to consider switching to the hash plan if we start out using the non-hashed plan but find a lot more upper rows going by than we expected. I have therefore left some minor inefficiencies in place, such as initializing both subplans even though we will currently only use one.
* Performance fix for new anti-join code in nodeMergejoin.c: after finding aTom Lane2008-08-15
| | | | | | | | | | | | | | | | | | match in antijoin mode, we should advance to next outer tuple not next inner. We know we don't want to return this outer tuple, and there is no point in advancing over matching inner tuples now, because we'd just have to do it again if the next outer tuple has the same merge key. This makes a noticeable difference if there are lots of duplicate keys in both inputs. Similarly, after finding a match in semijoin mode, arrange to advance to the next outer tuple after returning the current match; or immediately, if it fails the extra quals. The rationale is the same. (This is a performance bug in existing releases; perhaps worth back-patching? The planner tries to avoid using mergejoin with lots of duplicates, so it may not be a big issue in practice.) Nestloop and hash got this right to start with, but I made some cosmetic adjustments there to make the corresponding bits of logic look more similar.
* Implement SEMI and ANTI joins in the planner and executor. (Semijoins replaceTom Lane2008-08-14
| | | | | | | | | | | | | | the old JOIN_IN code, but antijoins are new functionality.) Teach the planner to convert appropriate EXISTS and NOT EXISTS subqueries into semi and anti joins respectively. Also, LEFT JOINs with suitable upper-level IS NULL filters are recognized as being anti joins. Unify the InClauseInfo and OuterJoinInfo infrastructure into "SpecialJoinInfo". With that change, it becomes possible to associate a SpecialJoinInfo with every join attempt, which permits some cleanup of join selectivity estimation. That needs to be taken much further than this patch does, but the next step is to change the API for oprjoin selectivity functions, which seems like material for a separate patch. So for the moment the output size estimates for semi and especially anti joins are quite bogus.
* Install checks in executor startup to ensure that the tuples produced by anTom Lane2008-08-08
| | | | | | | | | | | | INSERT or UPDATE will match the target table's current rowtype. In pre-8.3 releases inconsistency can arise with stale cached plans, as reported by Merlin Moncure. (We patched the equivalent hazard on the SELECT side in Feb 2007; I'm not sure why we thought there was no risk on the insertion side.) In 8.3 and HEAD this problem should be impossible due to plan cache invalidation management, but it seems prudent to make the check anyway. Back-patch as far as 8.0. 7.x versions lack ALTER COLUMN TYPE, so there seems no way to abuse a stale plan comparably.
* Improve INTERSECT/EXCEPT hashing by realizing that we don't need to make anyTom Lane2008-08-07
| | | | | | | | | hashtable entries for tuples that are found only in the second input: they can never contribute to the output. Furthermore, this implies that the planner should endeavor to put first the smaller (in number of groups) input relation for an INTERSECT. Implement that, and upgrade prepunion's estimation of the number of rows returned by setops so that there's some amount of sanity in the estimate of which one is smaller.
* Support hashing for duplicate-elimination in INTERSECT and EXCEPT queries.Tom Lane2008-08-07
| | | | | | | | | | This completes my project of improving usage of hashing for duplicate elimination (aggregate functions with DISTINCT remain undone, but that's for some other day). As with the previous patches, this means we can INTERSECT/EXCEPT on datatypes that can hash but not sort, and it means that INTERSECT/EXCEPT without ORDER BY are no longer certain to produce sorted output.
* Do not allow Unique nodes to be scanned backwards. The code claimed that itTom Lane2008-08-05
| | | | | | | would work, but in fact it didn't return the same rows when moving backwards as when moving forwards. This would have no visible effect in a DISTINCT query (at least assuming the column datatypes use a strong definition of equality), but it gave entirely wrong answers for DISTINCT ON queries.
* Rearrange the querytree representation of ORDER BY/GROUP BY/DISTINCT itemsTom Lane2008-08-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | as per my recent proposal: 1. Fold SortClause and GroupClause into a single node type SortGroupClause. We were already relying on them to be struct-equivalent, so using two node tags wasn't accomplishing much except to get in the way of comparing items with equal(). 2. Add an "eqop" field to SortGroupClause to carry the associated equality operator. This is cheap for the parser to get at the same time it's looking up the sort operator, and storing it eliminates the need for repeated not-so-cheap lookups during planning. In future this will also let us represent GROUP/DISTINCT operations on datatypes that have hash opclasses but no btree opclasses (ie, they have equality but no natural sort order). The previous representation simply didn't work for that, since its only indicator of comparison semantics was a sort operator. 3. Add a hasDistinctOn boolean to struct Query to explicitly record whether the distinctClause came from DISTINCT or DISTINCT ON. This allows removing some complicated and not 100% bulletproof code that attempted to figure that out from the distinctClause alone. This patch doesn't in itself create any new capability, but it's necessary infrastructure for future attempts to use hash-based grouping for DISTINCT and UNION/INTERSECT/EXCEPT.
* As noted by Andrew Gierth, there's really no need any more to force a junkTom Lane2008-07-26
| | | | | | | | | | | | | | | | filter to be used when INSERT or SELECT INTO has a plan that returns raw disk tuples. The virtual-tuple-slot optimizations that were put in place awhile ago mean that ExecInsert has to do ExecMaterializeSlot, and that already copies the tuple if it's raw (and does so more efficiently than a junk filter, too). So get rid of that logic. This in turn means that we can throw away ExecMayReturnRawTuples, which wasn't used for any other purpose, and was always a kluge anyway. In passing, move a couple of SELECT-INTO-specific fields out of EState and into the private state of the SELECT INTO DestReceiver, as was foreseen in an old comment there. Also make intorel_receive use ExecMaterializeSlot not ExecCopySlotTuple, for consistency with ExecInsert and to possibly save a tuple copy step in some cases.
* Adjust things so that the query_string of a cached plan and the sourceText ofTom Lane2008-07-18
| | | | | | | | | | | | | | | | | | | | | | | | a portal are never NULL, but reliably provide the source text of the query. It turns out that there was only one place that was really taking a short-cut, which was the 'EXECUTE' utility statement. That doesn't seem like a sufficiently critical performance hotspot to justify not offering a guarantee of validity of the portal source text. Fix it to copy the source text over from the cached plan. Add Asserts in the places that set up cached plans and portals to reject null source strings, and simplify a bunch of places that formerly needed to guard against nulls. There may be a few places that cons up statements for execution without having any source text at all; I found one such in ConvertTriggerToFK(). It seems sufficient to inject a phony source string in such a case, for instance ProcessUtility((Node *) atstmt, "(generated ALTER TABLE ADD FOREIGN KEY command)", NULL, false, None_Receiver, NULL); We should take a second look at the usage of debug_query_string, particularly the recently added current_query() SQL function. ITAGAKI Takahiro and Tom Lane
* Provide a function hook to let plug-ins get control around ExecutorRun.Tom Lane2008-07-18
| | | | ITAGAKI Takahiro
* Fix mis-calculation of extParam/allParam sets for plan nodes, as seen inTom Lane2008-07-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | bug #4290. The fundamental bug is that masking extParam by outer_params, as finalize_plan had been doing, caused us to lose the information that an initPlan depended on the output of a sibling initPlan. On reflection the best thing to do seemed to be not to try to adjust outer_params for this case but get rid of it entirely. The only thing it was really doing for us was to filter out param IDs associated with SubPlan nodes, and that can be done (with greater accuracy) while processing individual SubPlan nodes in finalize_primnode. This approach was vindicated by the discovery that the masking method was hiding a second bug: SS_finalize_plan failed to remove extParam bits for initPlan output params that were referenced in the main plan tree (it only got rid of those referenced by other initPlans). It's not clear that this caused any real problems, given the limited use of extParam by the executor, but it's certainly not what was intended. I originally thought that there was also a problem with needing to include indirect dependencies on external params in initPlans' param sets, but it turns out that the executor handles this correctly so long as the depended-on initPlan is earlier in the initPlans list than the one using its output. That seems a bit of a fragile assumption, but it is true at the moment, so I just documented it in some code comments rather than making what would be rather invasive changes to remove the assumption. Back-patch to 8.1. Previous versions don't have the case of initPlans referring to other initPlans' outputs, so while the existing logic is still questionable for them, there are not any known bugs to be fixed. So I'll refrain from changing them for now.
* Improve our #include situation by moving pointer types away from theAlvaro Herrera2008-06-19
| | | | | | | corresponding struct definitions. This allows other headers to avoid including certain highly-loaded headers such as rel.h and relscan.h, instead using just relcache.h, heapam.h or genam.h, which are more lightweight and thus cause less unnecessary dependencies.
* Refactor SPI_cursor_open/SPI_cursor_open_with_args so that the latter setsTom Lane2008-06-01
| | | | | | | | the PARAM_FLAG_CONST flag on the parameters that are passed into the portal, while the former's behavior is unchanged. This should only affect the case where the portal is executing an EXPLAIN; it will cause the generated plan to look more like what would be generated if the portal were actually executing the command being explained. Per gripe from Pavel.
* Add support for tracking call counts and elapsed runtime for user-definedTom Lane2008-05-15
| | | | | | | | | | functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
* Move the "instr_time" typedef and associated macros into a new headerTom Lane2008-05-14
| | | | | | | | | file portability/instr_time.h, and add a couple more macros to eliminate some abstraction leakage we formerly had. Also update psql to use this header instead of its own copy of nearly the same code. This commit in itself is just code cleanup and shouldn't change anything. It lays some groundwork for the upcoming function-stats patch, though.
* This is the patch replace offnum++ by OffsetNumberNext, to beBruce Momjian2008-05-13
| | | | | | consistent. OffsetNumberNext() has some casting that makes it useful. Fujii Masao
* Improve snapshot manager by keeping explicit track of snapshots.Alvaro Herrera2008-05-12
| | | | | | | | | | | | | There are two ways to track a snapshot: there's the "registered" list, which is used for arbitrary long-lived snapshots; and there's the "active stack", which is used for the snapshot that is considered "active" at any time. This also allows users of snapshots to stop worrying about snapshot memory allocation and freeing, and about using PG_TRY blocks around ActiveSnapshot assignment. This is all done automatically now. As a consequence, this allows us to reset MyProc->xmin when there are no more snapshots registered in the current backend, reducing the impact that long-running transactions have on VACUUM.
* Restructure some header files a bit, in particular heapam.h, by removing someAlvaro Herrera2008-05-12
| | | | | | | | | | | | unnecessary #include lines in it. Also, move some tuple routine prototypes and macros to htup.h, which allows removal of heapam.h inclusion from some .c files. For this to work, a new header file access/sysattr.h needed to be created, initially containing attribute numbers of system columns, for pg_dump usage. While at it, make contrib ltree, intarray and hstore header files more consistent with our header style.
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-03 22:42:48 +0000