Thread: Using textin/textout vs. scribbling around
I am tempted to replace all attempts to build text data on your own (with VARDATA, VARHDRSZ, etc.) with proper calls to textin/textout in all places that can't claim to be truly internal (especially all contrib). The background is that the internal format might change sometime when more locale features are implemented (see recent idea). Is this a good idea? -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter Eisentraut <peter_e@gmx.net> writes: > I am tempted to replace all attempts to build text data on your own (with > VARDATA, VARHDRSZ, etc.) with proper calls to textin/textout in all places > that can't claim to be truly internal (especially all contrib). Other than contrib, what places do you have in mind? > The background is that the internal format might change sometime when > more locale features are implemented (see recent idea). Is this a > good idea? Not sure. The I/O interface --- specifically the dependency on null-terminated strings --- isn't necessarily graven on stone tablets either. It could end up that this change adds more future work rather than preventing it. I'd be inclined to wait until we actually do change the internal representation of text, if we do so, before expending this effort. regards, tom lane
I am tempted to replace all attempts to build text data on your own (with VARDATA, VARHDRSZ, etc.) with proper callsto textin/textout in all places that can't claim to be truly internal (especially all contrib). The background isthat the internal format might change sometime when more locale features are implemented (see recent idea). Is this agood idea? I would be in favor of this for the following reasons. One of the great advantages of PostgreSQL is that adding new types is relatively straightforward. In many cases new types could be coded largely in terms of preexisting types. An example I am facing currently involves the problem of constructing basically a TEXT type with rather unusual parsing and output semantics. If a reasonably well-encapsulated version of the TEXT type existed--including header files with the right granularity and with the right functions provided in an installed library--the natural means of providing the new type we need would be to simply define a type with different *in/*out functions implemented over an instance of the TEXT internal data representation. Peter's suggestion appears to be a natural step towards the goal of being able to provide a defined interface that could be used for extensions. The concern that the _external_ format might change seems counter to the effort of providing a stable platform for extending PostgreSQL. If there is a serious possibility that this might occur, and because of that we cannot provide any external interface to the predefined types, then the well-known advantages of composing software modules from well-defined and well-tested components will be largely lost for anyone wishing to rapidly extend the system. Cheers, Brook
> Peter's suggestion appears to be a natural step towards the goal of > being able to provide a defined interface that could be used for > extensions. The concern that the _external_ format might change seems > counter to the effort of providing a stable platform for extending > PostgreSQL. If there is a serious possibility that this might occur, > and because of that we cannot provide any external interface to the > predefined types, then the well-known advantages of composing software > modules from well-defined and well-tested components will be largely > lost for anyone wishing to rapidly extend the system. Most of the entension API's are written by commercial companies with closed-source code, so they have to have an API to interface to their programs. Also, the API's are often unsuccessful because they are either unnecessarily complex or can't adapt to new features. We ship the code and I think an API could actually hurt us in the long run. For example, when we added TOAST, it changed how we had to do a few things. No one could have anticipated it, and with a few changes all the plugins worked just like native code. I don't think an API would have helped, or if it did, it would have necessiated overhead not present in the native types. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026