Re: parsing binary varchar[]-s
От | Tom Lane |
---|---|
Тема | Re: parsing binary varchar[]-s |
Дата | |
Msg-id | 15573.1090891023@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | parsing binary varchar[]-s (Igor Shevchenko <igor@carcass.ath.cx>) |
Список | pgsql-general |
Igor Shevchenko <igor@carcass.ath.cx> writes: > I use binary mode for sending params and receiving data using libpq with > protocol v3; PostgreSQL version is 7.4.3. > Here, varchar[]-s are returned in binary mode; they're generated from internal > structs by "array_send" function in src/backend/utils/adt/arrayfuncs.c. > PQftype(..) returns 1015 for those columns. I couldn't find any #define for > this OID -- does this mean it can change in future pg releases ? It's "_varchar" in pg_type.h, and no the OID is not likely to change. (Any OID under 10000 is manually assigned and we would have to go out of our way to change it.) > Also, can I safely use the binary format as described (by the code) in > "array_send" ? Is this interface is frozen, as a part of protocol v3 > spec ? Yes, the intention is that those formats are frozen. We haven't gotten around to collecting the information in a document, so you have to look at the code, but it's supposed to not change. At least up to a point ;-). Sooner or later we are going to want to support null elements within arrays, and that will surely impact the internal format as well as the transmitted format. My guess is that arrays that do not contain any nulls will look the same as now, but if there are nulls then a bit will be set in the flags word and we'll insert a null bitmap someplace. So I'd strongly recommend checking the flags word and punting if it contains a value you do not recognize. regards, tom lane
В списке pgsql-general по дате отправления: