Re: Macros for typtype (was Re: [HACKERS] Arrays of Complex Types)
Tom Lane wrote:
Why not enums? ;-)
Well, macros is how we do it elsewhere for char system columns.
I'm not sure we could rely on the behavior if we declared
pg_type.typtype as an enum type ... and if we don't, there's not
much point.
I was thinking C enums:
enum typtype_type {
TYPTYPE_BASE = 'b',
TYPTYPE_COMPOSITE = 'c',
TYPTYPE_DOMAIN = 'd',
TYPTYPE_ENUM = 'e',
TYPTYPE_PSEUDO = 'p'
};
I'm not sure if this is better.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: Macros for typtype (was Re: [HACKERS] Arrays of Complex Types)
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm not sure we could rely on the behavior if we declared
pg_type.typtype as an enum type ... and if we don't, there's not
much point.
I was thinking C enums:
enum typtype_type {
TYPTYPE_BASE = 'b',
TYPTYPE_COMPOSITE = 'c',
TYPTYPE_DOMAIN = 'd',
TYPTYPE_ENUM = 'e',
TYPTYPE_PSEUDO = 'p'
};
I'm not sure if this is better.
What bothers me about that is I don't think the C spec mandates the
representation width. If we could guarantee that enum typtype_type
was 1 byte I'd be all for it.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: Macros for typtype (was Re: [HACKERS] Arrays of Complex Types)
Tom Lane wrote:
What bothers me about that is I don't think the C spec mandates the
representation width. If we could guarantee that enum typtype_type
was 1 byte I'd be all for it.
The width is 4 both for the macro and the enum case. Both
#define TYPTYPE_BASE 'b'
and
enum ... {
TYPTYPE_BASE = 'b',
effectively generate int constants named TYPTYPE_BASE with decimal value
98. So there are no storage advantages either way.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: Macros for typtype (was Re: [HACKERS] Arrays of Complex Types)
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
What bothers me about that is I don't think the C spec mandates the
representation width. If we could guarantee that enum typtype_type
was 1 byte I'd be all for it.
The width is 4 both for the macro and the enum case. Both
#define TYPTYPE_BASE 'b'
and
enum ... {
TYPTYPE_BASE = 'b',
effectively generate int constants named TYPTYPE_BASE with decimal value
98. So there are no storage advantages either way.
That's not accurate at all. The macro case gives you a constant you can only
use to initialize integer variables and members that are explicitly declared
with some integral type. If we consistently declare them char then they'll
be predictably 1 byte long.
The enum case does two things. It defines a syntactic meaning for the label,
*and* it defines a thing enum typtype which can be used to define variables
and members. If the latter is used then Tom is saying the standard doesn't
specify what width the variable or member will be.
We could use enum {} to define the labels and then make a rule that all actual
variables should be declared using char rather than declaring them as enum
typtype. But I fear somebody would get that wrong some day. The worst thing
is that it might work on their compiler or it might even work on all compilers
and just silently be causing things to be aligned differently than they
expect.
On the other hand it I don't really think it would cause any problems if
people stored their typtypes in integers. Except for the actual FormData_pg_*
structures the precise alignment doesn't actually matter for anything does it?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: Macros for typtype (was Re: [HACKERS] Arrays of Complex Types)
Gregory Stark wrote:
The width is 4 both for the macro and the enum case. Both
#define TYPTYPE_BASE 'b'
and
enum ... {
TYPTYPE_BASE = 'b',
effectively generate int constants named TYPTYPE_BASE with decimal
value 98. So there are no storage advantages either way.
That's not accurate at all.
How so?
The macro case gives you a constant you
can only use to initialize integer variables and members that are
explicitly declared with some integral type. If we consistently
declare them char then they'll be predictably 1 byte long.
But character constants are actually ints, so when you do what you
describe then the compiler has to generate code to copy a four-byte
integer into a single byte. (Of course that can be optimized away,
probably.)
The enum case does two things. It defines a syntactic meaning for the
label, *and* it defines a thing enum typtype which can be used to
define variables and members. If the latter is used then Tom is
saying the standard doesn't specify what width the variable or member
will be.
The standard says that enums are the same as ints. So when you assign
an enum label to a char variable, then compiler has to generate code to
copy a four-byte integer into a single byte. (Of course that can be
optimized away, probably.)
The fact that you can also declare variables of the enum type is not
under consideration here.
QED
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Bug in UTF8-Validation Code?
On Sat, Mar 31, 2007 at 07:47:21PM -0700, Mark Dilger wrote: OK, I can take a stab at fixing this. I'd like to state some assumptions so people can comment and reply: I assume that I need to fix *all* cases where invalid byte encodings get into the database through functions shipped in the core distribution. Yes. I assume I do not need to worry about people getting bad data into the system through their own database extensions. That'd be rather difficult :) I assume that the COPY problem discussed up-thread goes away once you eliminate all the paths by which bad data can get into the system. However, existing database installations with bad data already loaded will not be magically fixed with these code patches. Correct. Do any of the string functions (see http://www.postgresql.org/docs/8.2/interactive/functions-string.html) run the risk of generating invalid utf8 encoded strings? Do I need to add checks? Are there known bugs with these functions in this regard? I don't think so. They'd be bugs if they were... If not, I assume I can add mbverify calls to the various input routines (textin, varcharin, etc) where invalid utf8 could otherwise enter the system. The only hard part is handling where the escaping and unescaping is happening... I assume that this work can be limited to HEAD and that I don't need to back-patch it. (I suspect this assumption is a contentious one.) At the very least I'd start with HEAD. Whether it gets backpatched probably depends on how invasive it ends up being... There's also the performance angle. The current mbverify is very inefficient for encodings like UTF-8. You might need to refactor a bit there... Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] Last minute mini-proposal (I know, Iknow)forPQexecf()
I don't necessarily object to PQexecf() as a shortcut for some multi-step operation, but I don't think you've got the format string semantics down yet. I'm thinking that we could start with the standard conversion specifiers - those are well understood and would be expected by just about any C developer. In particular, the %d, %u, %e, and %f format specifiers are immediately useful. If we start with the standard set, you can start to use PQexecf() immediately and we could promise to maintain *at least* that set. We can add more specifiers (for proper quoting and such) later - we can't break existing client applications if we just add to the set of supported specifiers; the function gets more useful as time goes by. -- Korry
Re: [HACKERS] Column storage positions
On 2/20/07, Phil Currier [EMAIL PROTECTED] wrote: Inspired by this thread [1], and in particular by the idea of storing three numbers (permanent ID, on-disk storage position, display position) for each column, I spent a little time messing around with a prototype implementation of column storage positions to see what kind of difference it would make. Phil, did you make any progress with your patch? Your results seemed very encouraging and your implementation interesting. IIRC, the problem was that you weren't interested in working on the visual/mysqlish column ordering. As the plan was to decouple column ordering in three different orderings, I don't think it's really a problem if your implementation doesn't support one of them (at least if it doesn't prevent us from having the visual one someday). Is there any chance you keep us posted with your progress and post a preliminary patch exposing your design choices? This could allow other people to see if there are interesting results with their particular database and workload. It's too late for 8.3 but it could be a nice thing to have in 8.4. Thanks in advance. Regards. -- Guillaume ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Bug in UTF8-Validation Code?
On 2007-04-01, Mark Dilger [EMAIL PROTECTED] wrote: Do any of the string functions (see http://www.postgresql.org/docs/8.2/interactive/functions-string.html) run the risk of generating invalid utf8 encoded strings? Do I need to add checks? Are there known bugs with these functions in this regard? The chr() function returns an octet, rather than a character; this is clearly wrong and needs fixing. -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: Macros for typtype (was Re: [HACKERS] Arrays of Complex Types)
Gregory Stark [EMAIL PROTECTED] writes:
We could use enum {} to define the labels and then make a rule that
all actual variables should be declared using char rather than
declaring them as enum typtype. But I fear somebody would get that
wrong some day.
Yeah, that seems to me to be just asking for trouble.
On the other hand it I don't really think it would cause any problems
if people stored their typtypes in integers. Except for the actual
FormData_pg_* structures the precise alignment doesn't actually matter
for anything does it?
The layout of the FormData struct is exactly the sticking point. If the
compiler makes the size or alignment of a struct field different from
what the tuple packing/unpacking code does for the corresponding column
type, we've got big trouble.
As for Peter's claim that the storage of an enum field is always int,
I think the C spec says otherwise. In 6.7.2.2 of C99 I see
[#4] Each enumerated type shall be compatible with an
integer type. The choice of type is
implementation-defined, 97) but shall be capable of
representing the values of all the members of the
enumeration. The enumerated type is incomplete until after
the } that terminates the list of enumerator declarations.
97) An implementation may delay the choice of which integer
type until all enumeration constants have been seen.
It seems clear to me that this authorizes, but *does not require*,
the compiler to store an enum field in a byte or short instead of
an int when all the declared values will fit. So if we tried to
do this, we'd have the problem of needing compiler-specific data
type information entered in pg_type.
Perhaps all C compilers do this alike, but how would we know?
Anyway the possible gain seems not worth the risk to me.
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Last minute mini-proposal (I know, Iknow)forPQexecf()
[EMAIL PROTECTED] writes: I don't necessarily object to PQexecf() as a shortcut for some multi-step operation, but I don't think you've got the format string semantics down yet. I'm thinking that we could start with the standard conversion specifiers - those are well understood and would be expected by just about any C developer. In particular, the %d, %u, %e, and %f format specifiers are immediately useful. If we start with the standard set, you can start to use PQexecf() immediately and we could promise to maintain *at least* that set. That's exactly the approach I don't want to take. To implement our quoting-escape additions, we'll have to stop relying on sprintf and implement for ourselves whatever standard C escapes we want to support. Then we'd have a backwards compatibility problem anywhere that the local sprintf() implements escapes that go beyond the standard. That means we'd be buying into *at least* as much complexity as is in src/port/snprintf.c, probably rather more, plus ongoing portability headaches while we find out what people happen to have depended on. And that's before we've added any value at all. I think it's simply not sane to start off with an sprintf-based implementation when we fully intend to have custom code later. We need a small, tightly specified set of escapes so that we aren't forced to support a pile of stuff that has little if any use for SQL-query construction. As an example, I see the use for %d but not the use for %-012.6d, to say nothing of $-reordering. But shipping a stopgap version of PQexecf would lock us into supporting all of that cruft. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Oracle indemnifies PostgreSQL on its patents
On Sun, April 1, 2007 01:32, Tom Lane wrote: The idea of OIN is to have a large patent pool that can be counter-asserted against anyone who doesn't want to play nice. Mutual assured destruction in the patent sphere, if you will. And from the participants' point of view, I suppose the big attraction must be that they do away with a threat to their patents. If you have a patent that matches what some open project (not worth suing) has been doing for the past few years, then anyone else you might want to sue about the patent could point to that project and say if you have a valid patent, why didn't you say something when they infringed it? Jeroen ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Last minute mini-proposal (I know, Iknow)forPQexecf()
That's exactly the approach I don't want to take. To implement our quoting-escape additions, we'll have to stop relying on sprintf and implement for ourselves whatever standard C escapes we want to support. Ok - then it seems like it might make sense to implement PQexecf() in terms of src/port/snprintf.c (and enhance that family of functions to support the quoting conversion specifiers that we want). Let's just pick up this discussion in the next release cycle. Bruce - can you add a TODO for this topic? Thanks. -- Korry -- Korry Douglas[EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com
Re: Macros for typtype (was Re: [HACKERS] Arrays of Complex Types)
Tom Lane wrote: It seems clear to me that this authorizes, but *does not require*, the compiler to store an enum field in a byte or short instead of an int when all the declared values will fit. So if we tried to do this, we'd have the problem of needing compiler-specific data type information entered in pg_type. FWIW, I never meant to suggest using enums tuple structures. I did, however, stumble over a case that appears to be handled similar to what I had in mind: see enum CoercionCodes in primnodes.h. Again, it's not really important, but it's interesting to see that there is precedent. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Bug in UTF8-Validation Code?
Martijn van Oosterhout wrote: There's also the performance angle. The current mbverify is very inefficient for encodings like UTF-8. You might need to refactor a bit there... There appears to be a lot of function call overhead in the current implementation. In pg_verify_mbstr, the function pointer pg_wchar_table.mbverify is called for each multibyte character in a multibyte string. Refactoring the way these table driven functions work would impact lots of other code. Just grep for all files #including mb/pg_wchar.h for the list of them. The list includes interfaces/libpq, and I'm wondering if software that links against postgres might rely on these function prototypes? mark ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Implicit casts to text
The attached patch changes all implicit casts to text to assignment and cleans up the associated regression test damage. This change has been discussed for the longest time; I propose that we bite the bullet and do it now. The issue described in http://archives.postgresql.org/pgsql-hackers/2007-02/msg01729.php should also be fixed but can be considered separately later. -- Peter Eisentraut http://developer.postgresql.org/~petere/ diff -cr ../cvs-pgsql/src/include/catalog/pg_cast.h ./src/include/catalog/pg_cast.h *** ../cvs-pgsql/src/include/catalog/pg_cast.h 2007-02-03 15:06:55.0 +0100 --- ./src/include/catalog/pg_cast.h 2007-04-01 22:26:13.0 +0200 *** *** 264,304 /* * Cross-category casts to and from TEXT - * - * For historical reasons, most casts to TEXT are implicit. This is BAD - * and should be reined in. */ ! DATA(insert ( 20 25 1289 i )); DATA(insert ( 25 20 1290 e )); ! DATA(insert ( 21 25 113 i )); DATA(insert ( 25 21 818 e )); ! DATA(insert ( 23 25 112 i )); DATA(insert ( 25 23 819 e )); ! DATA(insert ( 26 25 114 i )); DATA(insert ( 25 26 817 e )); DATA(insert ( 25 650 1714 e )); ! DATA(insert ( 700 25 841 i )); DATA(insert ( 25 700 839 e )); ! DATA(insert ( 701 25 840 i )); DATA(insert ( 25 701 838 e )); DATA(insert ( 829 25 752 e )); DATA(insert ( 25 829 767 e )); DATA(insert ( 650 25 730 e )); DATA(insert ( 869 25 730 e )); DATA(insert ( 25 869 1713 e )); ! DATA(insert ( 1082 25 749 i )); DATA(insert ( 25 1082 748 e )); ! DATA(insert ( 1083 25 948 i )); DATA(insert ( 25 1083 837 e )); ! DATA(insert ( 1114 25 2034 i )); DATA(insert ( 25 1114 2022 e )); ! DATA(insert ( 1184 25 1192 i )); DATA(insert ( 25 1184 1191 e )); ! DATA(insert ( 1186 25 1193 i )); DATA(insert ( 25 1186 1263 e )); ! DATA(insert ( 1266 25 939 i )); DATA(insert ( 25 1266 938 e )); ! DATA(insert ( 1700 25 1688 i )); DATA(insert ( 25 1700 1686 e )); DATA(insert ( 142 25 2922 e )); DATA(insert ( 25 142 2896 e )); --- 264,301 /* * Cross-category casts to and from TEXT */ ! DATA(insert ( 20 25 1289 a )); DATA(insert ( 25 20 1290 e )); ! DATA(insert ( 21 25 113 a )); DATA(insert ( 25 21 818 e )); ! DATA(insert ( 23 25 112 a )); DATA(insert ( 25 23 819 e )); ! DATA(insert ( 26 25 114 a )); DATA(insert ( 25 26 817 e )); DATA(insert ( 25 650 1714 e )); ! DATA(insert ( 700 25 841 a )); DATA(insert ( 25 700 839 e )); ! DATA(insert ( 701 25 840 a )); DATA(insert ( 25 701 838 e )); DATA(insert ( 829 25 752 e )); DATA(insert ( 25 829 767 e )); DATA(insert ( 650 25 730 e )); DATA(insert ( 869 25 730 e )); DATA(insert ( 25 869 1713 e )); ! DATA(insert ( 1082 25 749 a )); DATA(insert ( 25 1082 748 e )); ! DATA(insert ( 1083 25 948 a )); DATA(insert ( 25 1083 837 e )); ! DATA(insert ( 1114 25 2034 a )); DATA(insert ( 25 1114 2022 e )); ! DATA(insert ( 1184 25 1192 a )); DATA(insert ( 25 1184 1191 e )); ! DATA(insert ( 1186 25 1193 a )); DATA(insert ( 25 1186 1263 e )); ! DATA(insert ( 1266 25 939 a )); DATA(insert ( 25 1266 938 e )); ! DATA(insert ( 1700 25 1688 a )); DATA(insert ( 25 1700 1686 e )); DATA(insert ( 142 25 2922 e )); DATA(insert ( 25 142 2896 e )); *** *** 306,312 /* * Cross-category casts to and from VARCHAR * ! * We support all the same casts as for TEXT, but none are implicit. */ DATA(insert ( 20 1043 1289 a )); DATA(insert ( 1043 20 1290 e )); --- 303,309 /* * Cross-category casts to and from VARCHAR * ! * We support all the same casts as for TEXT. */ DATA(insert ( 20 1043 1289 a )); DATA(insert ( 1043 20 1290 e )); diff -cr ../cvs-pgsql/src/test/regress/expected/foreign_key.out ./src/test/regress/expected/foreign_key.out *** ../cvs-pgsql/src/test/regress/expected/foreign_key.out 2007-02-14 19:35:53.0 +0100 --- ./src/test/regress/expected/foreign_key.out 2007-04-01 22:45:19.0 +0200 *** *** 1125,1134 FOREIGN KEY (x3) REFERENCES pktable(id1); ERROR: foreign key constraint fk_3_1 cannot be implemented DETAIL: Key columns x3 and id1 are of incompatible types: real and integer. ! -- should succeed ! -- int4 promotes to text, so this is allowed (though pretty durn debatable) ALTER TABLE fktable ADD CONSTRAINT fk_1_2 FOREIGN KEY (x1) REFERENCES pktable(id2); -- int4 promotes to real ALTER TABLE fktable ADD CONSTRAINT fk_1_3 FOREIGN KEY (x1) REFERENCES pktable(id3); --- 1125,1136 FOREIGN KEY (x3) REFERENCES pktable(id1); ERROR: foreign key constraint fk_3_1 cannot be implemented DETAIL: Key columns x3 and id1 are of incompatible types: real and integer. ! -- int4 does not promote to text ALTER TABLE fktable ADD CONSTRAINT fk_1_2 FOREIGN KEY (x1) REFERENCES pktable(id2); + ERROR: foreign key constraint fk_1_2 cannot be implemented + DETAIL: Key columns
Re: [PATCHES] [HACKERS] Full page writes improvement, code update
Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: Any page written during a backup has a backup block that would not be removable by Koichi's tool, so yes, you'd still be safe. How does it know not to do that? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings XLogInsert( ) already has a logic to determine if inserting WAL record is between pg_start_backup and pg_stop_backup. Currently it is used to remove full_page_writes when full_page_writes=off. We can use this to mark WAL records. We have one bit not used in WAL record header, the last bit of xl_info, where upper four bits are used to indicate the resource manager and three of the rest are used to indicate number of full page writes included in the record. In my proposal, this unused bit is used to mark that full page writes must not be removed at offline optimization by pg_compresslog. Regards; -- -- Koichi Suzuki -- Koichi Suzuki ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Column storage positions
On 4/1/07, Guillaume Smet [EMAIL PROTECTED] wrote: Phil, did you make any progress with your patch? Your results seemed very encouraging and your implementation interesting. IIRC, the problem was that you weren't interested in working on the visual/mysqlish column ordering. As the plan was to decouple column ordering in three different orderings, I don't think it's really a problem if your implementation doesn't support one of them (at least if it doesn't prevent us from having the visual one someday). I haven't done much with it since February, largely because my available free time evaporated. But I do intend to get back to it when I have a chance. But you're right, the storage position stuff I've worked on is completely independent from display positions, and certainly wouldn't prevent that being added separately. Is there any chance you keep us posted with your progress and post a preliminary patch exposing your design choices? This could allow other people to see if there are interesting results with their particular database and workload. Yeah, I'll try to clean things up and post a patch eventually. And if anyone feels like working on the display position piece, let me know; perhaps we could pool our efforts for 8.4. phil ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Column storage positions
Phil Currier wrote: I haven't done much with it since February, largely because my available free time evaporated. But I do intend to get back to it when I have a chance. But you're right, the storage position stuff I've worked on is completely independent from display positions, and certainly wouldn't prevent that being added separately. I agree with this comment from Tom last time it was discussed: In any case I think it's foolish not to tackle both issues at once. We know we'd like to have both features and we know that all the same bits of code need to be looked at to implement either. Just tackling the side of the problem that interests you is probably not the ideal way to go. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: Macros for typtype (was Re: [HACKERS] Arrays of Complex Types)
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane wrote: It seems clear to me that this authorizes, but *does not require*, the compiler to store an enum field in a byte or short instead of an int when all the declared values will fit. FWIW, I never meant to suggest using enums tuple structures. I did, however, stumble over a case that appears to be handled similar to what I had in mind: see enum CoercionCodes in primnodes.h. Again, it's not really important, but it's interesting to see that there is precedent. AFAIK, we don't store CoercionCodes in any system catalog columns. But now that you mention it there is at least one place where we do it like that: pg_depend.deptype is a char but its values are defined by enum DependencyType. I have some recollection of doing it that way because I was concerned that most places that cared about dependency types should be switch statements that covered all the possible values (which is pretty much the only benefit you get from doing it that way). Having just gone over the typtype uses, there are only a couple of places where we'd win from having that sort of compile-time check for typtype. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Bug in UTF8-Validation Code?
Mark Dilger [EMAIL PROTECTED] writes: Refactoring the way these table driven functions work would impact lots of other code. Just grep for all files #including mb/pg_wchar.h for the list of them. The list includes interfaces/libpq, and I'm wondering if software that links against postgres might rely on these function prototypes? No, we've never exported those with the intent that client code should use 'em. Doing so would require importing non-public headers, and anyone who does that can have no grounds for complaining if the headers change incompatibly. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Bug in UTF8-Validation Code?
Mark Dilger [EMAIL PROTECTED] writes: Refactoring the way these table driven functions work would impact lots of other code. Just grep for all files #including mb/pg_wchar.h for the list of them. The list includes interfaces/libpq, and I'm wondering if software that links against postgres might rely on these function prototypes? No, we've never exported those with the intent that client code should use 'em. Doing so would require importing non-public headers, and anyone who does that can have no grounds for complaining if the headers change incompatibly. I thought PQescapeString() of 8.3 uses mbverify functions to make sure that user supplied multibyte string is valid. -- Tatsuo Ishii SRA OSS, Inc. Japan ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Bug in UTF8-Validation Code?
Tatsuo Ishii [EMAIL PROTECTED] writes: No, we've never exported those with the intent that client code should use 'em. I thought PQescapeString() of 8.3 uses mbverify functions to make sure that user supplied multibyte string is valid. Certainly --- but we can change PQescapeString to match whatever we do with the pg_wchar functions. The question was whether we intend to support client application code (outside libpq) using those functions. That's definitely not the intent. exports.txt lists only PQmblen and pg_utf_mblen as exported (and I have to wonder why the latter is separately exported...), which means that client code on modern platforms isn't even capable of getting at the others. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
