Re: Do we need use more meaningful variables to replace 0 in catalog head files?
От | Tom Lane |
---|---|
Тема | Re: Do we need use more meaningful variables to replace 0 in catalog head files? |
Дата | |
Msg-id | 18237.1479053497@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Do we need use more meaningful variables to replace 0 in catalog head files? (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Do we need use more meaningful variables to replace 0
in catalog head files?
(Andres Freund <andres@anarazel.de>)
Re: Do we need use more meaningful variables to replace 0 in catalog head files? (Andrew Dunstan <andrew@dunslane.net>) |
Список | pgsql-hackers |
Andrew Dunstan <andrew@dunslane.net> writes: > I'm not convinced the line prefix part is necessary, though. What I'm > thinking of is something like this: > PROCDATA( oid=1242 name=boolin isstrict=t volatile=i parallel=s nargs=1 > rettype=bool argtypes="cstring" src=boolin ); We could go in that direction too, but the apparent flexibility to split entries into multiple lines is an illusion, at least if you try to go beyond a few lines; you'd end up with duplicated line sequences in different entries and thus ambiguity for patch(1). I don't have any big objection to the above, but it's not obviously better either. Some things we should try to resolve before settling definitively on a data representation: 1. Are we going to try to keep these things in the .h files, or split them out? I'd like to get them out, as that eliminates both the need to keep the things looking like macro calls, and the need for the data within the macro call to be at least minimally parsable as C. 2. Andrew's example above implies some sort of mapping between the keywords and the actual column names (or at least column positions). Where and how is that specified? 3. Also where are we going to provide the per-column default values? How does the converter script know which columns to convert to type oids, proc oids, etc? Is it going to do any data validation beyond that, and if so on what basis? 4. What will we do about the #define's that some of the .h files provide for (some of) their object OIDs? I assume that we want to move in the direction of autogenerating those macros a la fmgroids.h, but this needs a concrete spec as well. If we don't want this change to result in a big hit to the source code, we're probably going to need to be able to specify the macro names to generate in the data files. 5. One of the requirements that was mentioned in previous discussions was to make it easier to add new columns to catalogs. This format does that only to the extent that you don't have to touch entries that can use the default value for such a column. Is that good enough, and if not, what might we be able to do to make it better? > I'd actually like to roll up the DESCR lines in pg_proc.h into this too, > they strike me as a bit of a wart. But I'm flexible on that. +1, if we can come up with a better syntax. This together with the OID-macro issue suggests that there will be items in each data entry that correspond to something other than columns of the target catalog. But that seems fine. > If we can generalize this to other catalogs, then that will be good, but > my inclination is to handle the elephant in the room (pg_proc.h) and > worry about the gnats later. I think we want to do them all. pg_proc.h is actually one of the easier catalogs to work on presently, IMO, because the only kind of cross-references it has are type OIDs. Things like pg_amop are a mess. And I really don't want to be dealing with multiple notations for catalog data. Also I think this will be subject to Polya's paradox: designing a general solution will be easier and cleaner than a hack that works only for one catalog. regards, tom lane
В списке pgsql-hackers по дате отправления:
Следующее
От: Tom LaneДата:
Сообщение: Re: Do we need use more meaningful variables to replace 0 in catalog head files?