Zeoslib Portal

Hmm, made a funny sample

EgonHugeist , That was my impression here too. But a if ColumnResultSet.GetString() = '' then this '$'+IntToStr() can be used instead. and what if there already is a param named $0, $1... As long as PG doesn't require param names and doesn't use them, params can be named anyway you like ("$0&q...

EgonHugeist,

I wouldn't do that. There will be no speed decrease. But...
First of all PostgreSQL supports unnamed params. So we will have to give them names anyway.
Second, we will break working code for those who rely on current paramnames (or we'll have to add one more Option)

miab3,

you are probably calling ZStoredProc1.Open and then ZStoredProc1.FieldByName('p4')... ?

I think EgonHugeist was talking about ExecProc and then ParamByName('returnValue').

I wonder that the returnValue is empty?! Is this correct?

http://zeos.firmos.at/viewtopic.php?t=3547

EgonHugeist , well typecasts are not that bad thing. According to PG forums it's better to NOT specify parameter types in PQexecPrepared. Explicit parameter type can lead to bad plan. The weak spot of the index system is that *cross type* comparisons were unindexable until recently. So if you wrote...

EgonHugeist,
can I see your tests?

There are extra spaces in DDL. Try this DROP FUNCTION IF EXISTS abtest(integer, integer, character varying); CREATE OR REPLACE FUNCTION abtest(IN p1 integer, IN p2 integer, IN p3 character varying, OUT p4 integer, OUT p5 character varying) RETURNS record AS $BODY$ BEGIN p4 = p1 + p2 * 10; p5 = p3 ||...

EgonHugeist , That test did show me only that using this Statement by default will cause trouble for others too. Yes, that's true, but this problem will dissapear if we use API calls (PQprepare/PQexecPrepared). About protocols. Protocol 3 was introduced in Postgre 7.4, but support for prepared stat...

EgonHugeist , I fixed StandardConformingStrings test. I also perfomed tests on some IDE's. Delphi7, DelphiXE2/Win32 - seems to be OK, Lazarus 1.1/Win32 - have some errors. Also was i afraid about one thing: i did read in several JDBC examples that we do NOT need to escape the Strings. But i didn't ...

EgonHugeist,

if it helps - it happened in rev.1642

EgonHugeist , We can add an option enumeration type like toAcceptModifiers and on TZTokenizer.TokenizeStreamToList we can check for this option. If this option is not set we reset the Token.Type(ttBinary) back to ttQuoted.. What do you think? I absolutely don't mind :). Couldn't do it myself becaus...

EgonHugeist,

Ok. I think this looks good and can be done.

can you please look at this patch. It overrides CheckEscapeState and replaces the State. Can't say it's the fastest way, but the simplest.

EgonHugeist , 'E' was detected as ttWord. Then the next char is the #39(') and TZPostgreSQLQuoteState.NextToken breaks here. But if TZPostgreSQLQuoteState.NextToken knows about that 'E','B','X','U&' can be followed from a ttQuoted then we go on reading and change the result-state to an optional...

EgonHugeist , as far as I know, there is only 4 types of string "modifiers" in PG: E'abcd\n' - escaped strings B'1001' - bit-strings X'1FF' - hex-stings U&'abc\0422' - strings with Unicode escapes and all of them are just quoted strings. So if I understand you right, TZPostgreSQLWordS...