[GENERAL] ecpg observation

[Sirish Kumar]

Is following observation regarding "ecpg" correct ?

It is not possible to give different port number from embedded SQLs.
Following gives error on ecpg preprocessor :
exec sql connect to tcp:postgresql://localhost:1234/:dName ;
Where dName is a host variable for database name and 1234 is a port number.
The pre-processor cannot parse statement as the dName is a host variable.

Regards
S. Kumar

[GENERAL] finding predecessor

[Holger Klawitter]

Hi there,

is there any convenient way to find the predecessor of a record given
a particular order of the database? 

The following select seems a little bit too expensive.

create table tuples ( i int, j int, m int, k int );

select * from tuples
where ihttp://www.klawitter.de/

[GENERAL] Problem with SELECT on large negative INT4

[Nicolas Huillard]

I have a DB with is updated using MS Access. Primary keys are Int4 with default random 
values ("NuméroAuto" + "Aléatoire" in Access).
The DB is migrated as-is in Postgres, with tbl_prod.cle_prod field containing values 
from -2057496808 to 2139583719.
When I SELECT in the table, using the INT4 cle_prod value, PG doesn't find the tuple. 
When I SELECT using the VARCHAR(10) ref_prod value, PG finds the tuple, and show the 
right value for the cle_prod filed : the same as the one I SELECTed for...

This sounds like the long negative integer values given in PSQL is not converted 
correctly while executing.
Using a long positive integer value, all works like a charm...

Below is the queries type sto sho what append.
I'm using Postgres 6.5.2 from the RPMs.

Nicolas Huillard




gest=> select cle_prod, ref_prod from tbl_prod where ref_prod='4866VC';
   cle_prod|ref_prod
---+
-2057496808|4866VC  
(1 row)

gest=> select cle_prod, ref_prod from tbl_prod where cle_prod = -2057496808;
cle_prod|ref_prod
+
(0 rows)

gest=> \d tbl_prod
Table= tbl_prod
+--+--+---+
|  Field   |  Type| Length|
+--+--+---+
| cle_prod | int4 not null default nextval('" | 4 |
| ref_prod | varchar() not null   |10 |
...
+--+--+---+
Index:tbl_prod_pkey

gest=> select version();
version   
--
PostgreSQL 6.5.2 on i486-pc-linux-gnu, compiled by gcc 2.7.2.3
(1 row)

gest=> 

[GENERAL] Problem with search on INT4

[Nicolas Huillard]

I have a DB with is updated using MS Access. Primary keys are Int4 with default random 
values ("NuméroAuto" + "Aléatoire" in Access).
The DB is migrated as-is in Postgres, with tbl_prod.cle_prod field containing values 
from -2057496808 to 2139583719.
When I SELECT in the table, using the INT4 cle_prod value, PG doesn't find the tuple. 
When I SELECT using the VARCHAR(10) ref_prod value, PG finds the tuple, and show the 
right value for the cle_prod filed : the same as the one I SELECTed for...

This sounds like the long negative integer values given in PSQL is not converted 
correctly while executing.
Using a long positive integer value, all works like a charm...

Below is the queries type sto sho what append.
I'm using Postgres 6.5.2 from the RPMs.

Nicolas Huillard




gest=> select cle_prod, ref_prod from tbl_prod where ref_prod='4866VC';
   cle_prod|ref_prod
---+
-2057496808|4866VC  
(1 row)

gest=> select cle_prod, ref_prod from tbl_prod where cle_prod = -2057496808;
cle_prod|ref_prod
+
(0 rows)

gest=> \d tbl_prod
Table= tbl_prod
+--+--+---+
|  Field   |  Type| Length|
+--+--+---+
| cle_prod | int4 not null default nextval('" | 4 |
| ref_prod | varchar() not null   |10 |
...
+--+--+---+
Index:tbl_prod_pkey

gest=> select version();
version   
--
PostgreSQL 6.5.2 on i486-pc-linux-gnu, compiled by gcc 2.7.2.3
(1 row)

nutrigest=> 

[GENERAL] finding last element of an index

[Jim Mercer]

if i have a table:

CREATE TABLE booga
(
name   varchar(20),
addr   varchar(20)
);
CREATE UNIQUE INDEX booga_idx ON booga (name);

is there a fast way to find the last entry in index booga_idx?


-- 
[ Jim Mercer [EMAIL PROTECTED]  +1 416 506-0654 ]
[  Reptilian Research -- Longer Life through Colder Blood  ]
[  Don't be fooled by cheap Finnish imitations; BSD is the One True Code.  ]