Re: Patches + thoughts

Both applied.

Off the top of my head I don't know a reason we would not escape the
escape character.

The insert code was a patch written by someone else, and I think it
was written in the least obtrusive way (leaving the mainline code
alone and putting it all in export.c), so lacks a certain
cohesiveness.  I'm not faulting the author at all, I should have
reworked the code and integrated it better.

If I read you correctly, you are thinking of having mdb-schema (and
the gui version thereof) generate something like mysqldump or pg_dump
with all schemas, tables, data, keys, etc... in sequence?  I think
it's a good idea.  Next time I'm messing in that area, I'll see what
is to be done.

Brian

2011/2/19 Nirgal Vourgère <[email protected]>:
> On Friday 18 February 2011 19:38:19 Brian Bruns wrote:
>> I'd like to keep quote/escape (particularly quote, I can't think of a
>> case where escape is more than one char) as a string since it allows a
>> multicharacter delimiter, not as uncommon a convention as you might
>> think.
>
> Right.
> Attached is a revised version of export patch.
>
> That does not really anwser my question: "Should we escape the escape character ?"
> My patch does.
> If you or anyone don't like it, there is a #define DONT_ESCAPE_ESCAPE
>
> Attached is an update for Binary type (should not be treated as Memo).
>
>> I agree that the escaping needs some work as it is often not as simple
>> as adding a simple leading character, but that gets a little
>> complicated and we'd have to bake in some escaping styles rather than
>> the generic switch we now have.
>
> I agree.
>
> But I bet the INSERT version of mdb-export doesn't support charcters < 32 right now, nor non-utf8 characters above 127 (OLE).
>
> I guess the best solution would be to move the INSERT code into the schema exportation tools (backend.c).
> The insert would then occur before foreign keys setup. We could also set up the sequences (autonum/serial) automatically then. And have a full mdb->sql conversion tool with both schema and data.
>
> I don't really have the time for that. Would that be a good idea?
>
>> On unicode2ascii, I have no clue how string compression would work for
>> BIG5, but otherwise it basically punts on the overrun question, it's
>> up to the calling function to properly allocate the size which is
>> generally MDB_BIND_SIZE, which is 4 times the page size, so that
>> should accommodate any code set.
>
> I hit some surprised with props, because I was careless of the unciode conversion expanding size problem at first. I mean column name sizes.
> Anyways. I was thinking about Memo fields. I though the limit was 16k, so that mdbtools might fail after utf-8 conversion.
> But Memo field limit actually is 64k chars (192k bytes in utf-8), so we are in trouble anyways.
>
> Maybe all LVal should be handled the same way, with no automatic binding. We now have 3 versions of lval reading in data.c...
>
> Here's another hint: The table/column props internally have:
> - Name
> - type (like col_type)
> - Buffer (pointer + size)
> Right now, we are converting everything to a proper string, meaning we loose the type. We might want a kind of MdbVariant (type+buffer) that could be played with. Like numeric/date operations.
>
> I have the feeling a MdbVariant might be usefull for binding too. We could probably wrap a LVal reader in it.
>
> Ok, I stop daydreaming now... :)
>

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb