hi,
i am new for postgres sql.i have downloaded driver for postgres sql and trying to do connectivity through it.is it type 2 driver or type 4 driver..??-- Deepak PalSoftware Developer
Wicenet ltd.Pune(M.H)
On Jul 20 08:21, Dan Strömberg wrote:
I would like to know if it is possible to find out the datatypes in the
resultset of a query or a set returning
function without actually executing them ?
As Tom mentioned, there's support for this feature in the protocol
level, but I don't know any API
On 21.07.2006 11:12 Volkan YAZICI wrote:
As Tom mentioned, there's support for this feature in the protocol
level, but I don't know any API supports this yet.
I think if you run a query like the suggested one (or SELECT ... WHERE
1=2) the JDBC API will provide the necessary information via
Hi Deepak,PostgreSQL JDBC is a type 4 implementation (http://jdbc.postgresql.org/documentation/80/index.html)Thanks,Shoaib Mir
EnterpriseDBOn 7/21/06, deepak pal [EMAIL PROTECTED] wrote:
hi,
i am new for postgres sql.i have downloaded driver for postgres sql and trying to do connectivity through
Hi list,
i just wanted to delete my sandbox version of postgre and install the real
postgresql-database. unfortunately, the windows installer doesn't want to start
and keeps telling me that the windows installer service could not be accessed.
Strangely, i can start any other installer on the
Yes, that could be the case. We have a python function that imports
CSV files, which can take a long time, and that may have been running
during that time. I didn't look at the pg_lock file. What should I be
looking for?
On Jul 20, 2006, at 3:13 PM, Tom Lane wrote:
Claire McLister [EMAIL
Volkan YAZICI wrote:
On Jul 20 08:21, Dan Strömberg wrote:
I would like to know if it is possible to find out the datatypes in the
resultset of a query or a set returning
function without actually executing them ?
As Tom mentioned, there's support for this feature in the protocol
level, but
On Jul 21 09:02, Jacob Coby wrote:
Volkan YAZICI wrote:
As Tom mentioned, there's support for this feature in the protocol
level, but I don't know any API supports this yet. However, here's a
patch that adds Describe functionality for Prepared Statements and
Cursors to libpq:
On Fri, Jul 21, 2006 at 04:14:52PM +0300, Volkan YAZICI wrote:
On Jul 21 09:02, Jacob Coby wrote:
Volkan YAZICI wrote:
As Tom mentioned, there's support for this feature in the protocol
level, but I don't know any API supports this yet. However, here's a
patch that adds Describe
Claire McLister [EMAIL PROTECTED] writes:
Yes, that could be the case. We have a python function that imports
CSV files, which can take a long time, and that may have been running
during that time. I didn't look at the pg_lock file. What should I be
looking for?
A record with granted =
Martijn van Oosterhout wrote:
On Fri, Jul 21, 2006 at 04:14:52PM +0300, Volkan YAZICI wrote:
On Jul 21 09:02, Jacob Coby wrote:
Volkan YAZICI wrote:
As Tom mentioned, there's support for this feature in the protocol
level, but I don't know any API supports this yet. However, here's a
patch
On Jul 21 03:34, Martijn van Oosterhout wrote:
Really, I would have thought the PHP function would map directly to the
libpq PQftype() function. Although libpq returns the OID whereas the
PHP function returns the type. But I don't think that's what the
original user asked for given you need a
On Fri, 2006-07-21 at 14:17, Claire McLister wrote:
Yes, that could be the case. We have a python function that imports
CSV files, which can take a long time, and that may have been running
during that time. I didn't look at the pg_lock file. What should I be
looking for?
I have the
Thanks. I'll look into this next time it happens.
For now, I tried the create index commands again, and they worked in
a split-second. So, it must have been the lock contention, and not
the VACUUM'ng.
On Jul 21, 2006, at 6:45 AM, Tom Lane wrote:
Claire McLister [EMAIL PROTECTED] writes:
On Fri, Jul 21, 2006 at 05:07:08PM +0300, Volkan YAZICI wrote:
AFAICS, that's not possible with current parsing capabilities. See
related lines in
fe-protocol3.c:pqParseInput3()
102 /*
103 * Can't process if message body isn't all here yet.
104 */
My question is a bit off the path that you're taking with this issues, but I'd
like to add a twist to the discussion -- to meet my needs of course :)
Is it possible to simply retrieve Column Type (Numeric, Varchar, Int,...) data
for a given table using ecpg?
The reason I ask is that when I
On Jul 21 04:25, Martijn van Oosterhout wrote:
On Fri, Jul 21, 2006 at 05:07:08PM +0300, Volkan YAZICI wrote:
AFAICS, that's not possible with current parsing capabilities. See
related lines in
fe-protocol3.c:pqParseInput3()
102 /*
103 * Can't process if
Hello, I was wondering if someone could enlighten me as to the impact to
the entire database of running VACUUM FULL against a single table. The
reason I ask is that at company we work for we have a very large number
of queue type tables that fill up and empty out on a regular basis, on
the
Erik,
On Fri, 2006-07-21 at 17:13, Erik Jones wrote:
Hello, I was wondering if someone could enlighten me as to the impact to
the entire database of running VACUUM FULL against a single table. The
reason I ask is that at company we work for we have a very large number
of queue type tables
On Fri, Jul 21, 2006 at 05:47:32PM +0300, Volkan YAZICI wrote:
Did you see my comment about get partial result sets from libpq. for
asyncronous queries you can run PQftype as soon as you've received and
parsed the T record
We can run PQftype() on what, conn-result? (We can't use a
Csaba Nagy wrote:
Erik,
On Fri, 2006-07-21 at 17:13, Erik Jones wrote:
Hello, I was wondering if someone could enlighten me as to the impact to
the entire database of running VACUUM FULL against a single table. The
reason I ask is that at company we work for we have a very large number
Hi,
forget the last email. After rebooting it's working again. Don't know why or
how, but it's working...
Christian Rengstl 21.07.06 12.55 Uhr
Hi list,
i just wanted to delete my sandbox version of postgre and install the real
postgresql-database. unfortunately, the windows installer
On Fri, 2006-07-21 at 10:13, Erik Jones wrote:
Hello, I was wondering if someone could enlighten me as to the impact to
the entire database of running VACUUM FULL against a single table. The
reason I ask is that at company we work for we have a very large number
of queue type tables that
Hi all,
I'm trying to run pg_regress as part of a build of Postgres 8.1 on
Suse Linux Enterprise Server 9. I keep getting the following error:
./pg_regress: line 264: kill: (25049) - No such process
I chased the problem down to the following lines in pg_regress:
$bindir/postmaster -D
I found pg_prog.prorettype in the system catalogs , is it possible to
use that to find the resultset datatypes of a
set returning function ?
Anyway , maybe the odbc driver will work by using SQLDescribecol()
without executing it ?!
I found something in the archives where someone suggests that
Scott Marlowe wrote:
On Fri, 2006-07-21 at 10:13, Erik Jones wrote:
Hello, I was wondering if someone could enlighten me as to the impact to
the entire database of running VACUUM FULL against a single table. The
reason I ask is that at company we work for we have a very large number
of
On Fri, 21 Jul 2006 10:35:17 -0500
Erik Jones [EMAIL PROTECTED] wrote:
Csaba Nagy wrote:
[snip]
That is an excellent idea, however, what are the effects of CLUSTER on
empty tables? Considering that most of our queue tables sit empty until
their used, our main concern is keep the disk space
Jochem,
For a small number of processes and a large difference in time
between the 'loookup' speed and the 'work' I have used a two-step
process where you first get a batch of records and then try them
all in rapid succession. In pseudocode:
SELECT *
FROM table
WHERE condition
LIMIT
On Fri, 21 Jul 2006 11:40:32 -0500
Erik Jones [EMAIL PROTECTED] wrote:
No!!! The table is filled and entries are deleted one at a time, or in
groups, but definitely not all at once.So, then what is the
difference between scheduling regular vacuum on specific tables v.
scheduling
Eric E [EMAIL PROTECTED] writes:
I chased the problem down to the following lines in pg_regress:
$bindir/postmaster -D $PGDATA -F $postmaster_options
$LOGDIR/postmaster.log; 21
^
Is there really a semicolon there? There should not be (and isn't in
my
On Fri, 2006-07-21 at 11:40, Erik Jones wrote:
Scott Marlowe wrote:
On Fri, 2006-07-21 at 10:13, Erik Jones wrote:
Hello, I was wondering if someone could enlighten me as to the impact to
the entire database of running VACUUM FULL against a single table. The
reason I ask is that
Sorry - that semicolon is an artifact of a change I made - I attempted
to put
postmaster_pid=$! inside the executing statement, but as I discovered,
if you put it before last , you
get the backgrounded process before postmaster.
I'm presently checking out how the SLES init scripts work, but
Scott Marlowe wrote:
On Fri, 2006-07-21 at 11:40, Erik Jones wrote:
Scott Marlowe wrote:
On Fri, 2006-07-21 at 10:13, Erik Jones wrote:
Hello, I was wondering if someone could enlighten me as to the impact to
the entire database of running VACUUM FULL against a single table.
Scott Marlowe wrote:
On Fri, 2006-07-21 at 15:49, Erik Jones wrote:
Scott Marlowe wrote:
I'd use regular cronned vacuums on the tables that you know grown a lot
(or just hit the whole db and not worry about it) and run occasional
vacuum verbose / vacuum full verbose by hand to see if
On Fri, 2006-07-21 at 15:49, Erik Jones wrote:
Scott Marlowe wrote:
I'd use regular cronned vacuums on the tables that you know grown a lot
(or just hit the whole db and not worry about it) and run occasional
vacuum verbose / vacuum full verbose by hand to see if you have problems
with
Hi
There is a new installed PostgreSQL 8.1.4 running on Windows2003.
Last 3 days we get error message below incidentally. After first error, we
get the error frequently.
After restart the service, the error gone.
2006-07-13 19:43:57.218 192.168.3.14(1093) test user SELECTLOG: duration:
15.000
36 matches
Mail list logo
