On Sun, Jun 10, 2007 at 09:56:44PM +0200, Magnus Hagander wrote:
AFAIK, most other compilers delete their output if it's not valid. Is
there any particular reason why ecpg doesn't do this?
No, not really. Sometimes it comes handy to see what was already
processed, but you're right, it's not
Heikki Linnakangas [EMAIL PROTECTED] wrote:
True. On the other hand, if we issue writes in essentially random order,
we might fill the kernel buffers with random blocks and the kernel needs
to flush them to disk as almost random I/O. If we did the writes in
groups, the kernel has better
Yes, there is a use-case for it. If you don't have triggers or
transactional concerns on the table and you want users to be able to
truncate tables while not allowing them to do things like change the
table structure. I proposed a patch a while ago to implement a seperate
permission for
On Mon, 4 Jun 2007, Kris Jurka wrote:
On Mon, 4 Jun 2007, Andrew Dunstan wrote:
turnip_moth is also a Solaris 9 box and doesn't seem have the same issue.
Kris, is there anything unusual installed on the box that would make it
behave like this?
Not sure what's going on here. I did a
On Mon, 11 Jun 2007, ITAGAKI Takahiro wrote:
If the kernel can treat sequential writes better than random writes, is
it worth sorting dirty buffers in block order per file at the start of
checkpoints?
I think it has the potential to improve things. There are three obvious
and one subtle
On Mon, Jun 11, 2007 at 08:05:16AM +0200, Michael Meskes wrote:
On Sun, Jun 10, 2007 at 09:56:44PM +0200, Magnus Hagander wrote:
AFAIK, most other compilers delete their output if it's not valid. Is
there any particular reason why ecpg doesn't do this?
No, not really. Sometimes it comes
Hello,
Updatable cursors can be supported in PL/pgSQL.
Explicit PL/pgSQL cursors are named, then we need only skip CURRENT OF
clause in parsing of SQL statements.
Regards
Pavel Stehule
---(end of broadcast)---
TIP 6: explain analyze is your
On Mon, Jun 11, 2007 at 09:40:08AM +0200, Ewald Geschwinde wrote:
My problem is that some users don't have access to change the structure but
they wanted to delete all data from the table
they try truncate - does not work because not the owner
so they make a delete from a really big table
Martijn van Oosterhout wrote:
On Mon, Jun 11, 2007 at 09:40:08AM +0200, Ewald Geschwinde wrote:
My problem is that some users don't have access to change the structure but
they wanted to delete all data from the table
they try truncate - does not work because not the owner
so they make a delete
ITAGAKI Takahiro wrote:
Heikki Linnakangas [EMAIL PROTECTED] wrote:
True. On the other hand, if we issue writes in essentially random order,
we might fill the kernel buffers with random blocks and the kernel needs
to flush them to disk as almost random I/O. If we did the writes in
groups,
Hi Simon,
I'll be glad to test it for you when you're ready!
Thanks for looking at this issue.
Best regards,
On Sun, 10 Jun 2007, Simon Riggs wrote:
Date: Sun, 10 Jun 2007 23:55:32 +0100
From: Simon Riggs [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers list
Wouldn't it be far more logical to decide that if a user has the
permissions to do a DELETE FROM table; then they have permission to
do
a TRUNCATE? Why make an additional permission?
Truncate doesn't fire ON DELETE triggers.
Yes, but it would imho be ok if there are'nt any on delete
Hi,
I can probably figure it out on linux but I would like to do a one
click install based upon defined defaults for the Postgresql database
(creating it as a service and load my sql file which creates the
database) - has anyone written such a how to?
thanks
Tim
* Zeugswetter Andreas ADI SD ([EMAIL PROTECTED]) wrote:
Wouldn't it be far more logical to decide that if a user has the
permissions to do a DELETE FROM table; then they have permission to
do
a TRUNCATE? Why make an additional permission?
Truncate doesn't fire ON DELETE
On Mon, Jun 11, 2007 at 10:03:57AM +0200, Magnus Hagander wrote:
If you find the other behaviour useful, perhaps add a commandline switch
that makes it leave the file around? Just make the
remove-the-file-on-failure default.
Should be fixed now. I don't think such a command line switch is
Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I tried to repeat the DBT-2 runs with the oldestxmin refresh patch,
but to my surprise the baseline run with CVS head, without the patch,
behaved very differently than it did back in March.
I rerun the a
Tom Lane wrote:
Every so often, buildfarm member skylark reports a StartDb:2 failure,
as for instance here:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylarkdt=2007-06-10%2023:00:01
but the logs contain no trace of any actual failure. What's happening,
and why is the buildfarm failing
On Mon, Jun 11, 2007 at 10:23:06AM -0400, Andrew Dunstan wrote:
Tom Lane wrote:
Every so often, buildfarm member skylark reports a StartDb:2 failure,
as for instance here:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylarkdt=2007-06-10%2023:00:01
but the logs contain no trace of
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
The idea of one pipe per process is not really workable, because it
would mean having as many pipes as backends which does not sound very
good. But how about a mixed approach -- like have the all the backends
share a pipe,
Magnus Hagander wrote:
On Mon, Jun 11, 2007 at 10:23:06AM -0400, Andrew Dunstan wrote:
Tom Lane wrote:
Every so often, buildfarm member skylark reports a StartDb:2 failure,
as for instance here:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylarkdt=2007-06-10%2023:00:01
but the
Andrew Dunstan [EMAIL PROTECTED] writes:
I'll try to get a patch out for just the stderr case, which should be
back-patchable, then adjust the CSVlog patch to use it.
Sounds like a plan.
I'm thinking of handling the partial lines with a small dynahash of
StringInfo buffers, which get
Hi!
Still working on the ecpg-regression-tests-on-msvc. Update to follow
later today I hope. But for now:
I get the following error when trying to build the sql/parser.pgc test:
c:\prog\pgbin\pgsql\bin\ecpg --regression -o parser.c parser.pgc
parser.pgc:26: ERROR: syntax error at or
Hello,
It is past feature freeze which means we can't introduce new features.
It is possible to submit a patch for slightly different logging output?
Take the following:
INFO: analyzing pg_catalog.pg_authid
INFO: pg_authid: scanned 1 of 1 pages, containing 5 live rows and 0
dead rows; 5
Joshua D. Drake wrote:
Take the following:
INFO: analyzing pg_catalog.pg_authid
INFO: pg_authid: scanned 1 of 1 pages, containing 5 live rows and 0
dead rows; 5 rows in sample, 5 estimated total rows
The above is completely redundant. Why not just say:
INFO: pg_authid: scanned 1 of 1
SELECT 1 FROM test.dbo.a_003
gets about 60,000 records per second
SELECT '1' FROM test.dbo.a_003
gets about 600 records per second.
The cause is that postgres describes the return column as unknown
length 65534 in the 2nd case.
Since the value is a constant, it seems rather
Dann Corbit [EMAIL PROTECTED] writes:
SELECT 1 FROM test.dbo.a_003
gets about 60,000 records per second
SELECT '1' FROM test.dbo.a_003
gets about 600 records per second.
The cause is that postgres describes the return column as unknown
length 65534 in the 2nd case.
Postgres describes it
Dann Corbit [EMAIL PROTECTED] writes:
SELECT 1 FROM test.dbo.a_003
gets about 60,000 records per second
SELECT '1' FROM test.dbo.a_003
gets about 600 records per second.
The cause is that postgres describes the return column as unknown
length 65534 in the 2nd case.
Wait, back up.
-Original Message-
From: Gregory Stark [mailto:[EMAIL PROTECTED]
Sent: Monday, June 11, 2007 12:48 PM
To: Dann Corbit
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Selecting a constant question
Dann Corbit [EMAIL PROTECTED] writes:
SELECT 1 FROM test.dbo.a_003
On Mon, Jun 11, 2007 at 12:55:55PM -0700, Dann Corbit wrote:
The issue is this:
Postgres describes the column with a typmod of -1 (unknown) and a length
of 65534.
Postgres does no such thing. How can it possibly know the maximum size
of a column before executing the query?
Have a nice day,
Dann Corbit [EMAIL PROTECTED] writes:
The issue is this:
Postgres describes the column with a typmod of -1 (unknown) and a length
of 65534.
Oh, you're looking at typlen not typmod. Please observe the comments in
pg_type.h:
/*
* For a fixed-size type, typlen is the number of
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Monday, June 11, 2007 1:32 PM
To: Dann Corbit
Cc: Gregory Stark; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Selecting a constant question
Dann Corbit [EMAIL PROTECTED] writes:
The issue is this:
Tom Lane [EMAIL PROTECTED] writes:
Trying the example in psql seems to be about the same speed both ways, with
if anything a slight advantage to select '1'.
Fwiw I see a slight advantage for '1' as well. I wonder why.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
-Original Message-
From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
Sent: Monday, June 11, 2007 1:46 PM
To: Dann Corbit
Subject: Re: [HACKERS] Selecting a constant question
On Mon, Jun 11, 2007 at 01:29:37PM -0700, Dann Corbit wrote:
Our application is using the libPQ
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Dann Corbit
Sent: Monday, June 11, 2007 1:52 PM
To: Martijn van Oosterhout
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Selecting a constant question
-Original
Dann Corbit [EMAIL PROTECTED] writes:
Surely, we cannot be the only people who will need this information. If
(for example) someone wants to bind to a grid, then the maximum size has
to be known in advance.
In fact psql needs it and implements this. It has to skim through the entire
result
-Original Message-
From: Gregory Stark [mailto:[EMAIL PROTECTED]
Sent: Monday, June 11, 2007 2:41 PM
To: Dann Corbit
Cc: Martijn van Oosterhout; pgsql-hackers@postgresql.org; Larry McGhaw
Subject: Re: [HACKERS] Selecting a constant question
Dann Corbit [EMAIL PROTECTED] writes:
Dann Corbit wrote:
Dann Corbit [EMAIL PROTECTED] writes:
In fact psql needs it and implements this. It has to skim through the
entire
result set to calculate the column widths. It's quite a lot of work
but
the
server is in no better position to do it than psql.
Reading the data
These two calls make our remote queries via libpq about twice as fast on
average. It seems to me like it might be a nice addition to the core
product's libpq (I poked it into the spot where the Nagle algorithm is
turned off, but another place would be fine too). Can anyone give me a
reason why
-Original Message-
From: Alvaro Herrera [mailto:[EMAIL PROTECTED]
Sent: Monday, June 11, 2007 3:16 PM
To: Dann Corbit
Cc: Gregory Stark; Martijn van Oosterhout;
pgsql-hackers@postgresql.org;
Larry McGhaw
Subject: Re: [HACKERS] Selecting a constant question
Dann Corbit wrote:
Dann Corbit wrote:
Oh, you have the length information for each datum all right. It's on
the first four bytes of it.
Sure, but when I bind to a grid, I need to know a-priori how big the
biggest returned instance can be. Reading the entire data set twice to
learn the size of a constant
On Mon, Jun 11, 2007 at 03:18:33PM -0700, Dann Corbit wrote:
Sure, but when I bind to a grid, I need to know a-priori how big the
biggest returned instance can be. Reading the entire data set twice to
learn the size of a constant seems rather conceptually odd to me.
To be honest, the concept
Dann Corbit [EMAIL PROTECTED] writes:
Giving me the information about the data type will be enough. As an
example, in this case we have varchar data. If the server should be so
kind as to report varchar(1) for '1' or varchar(3) for '123' then I
would not have any difficulty binding the data
Dann Corbit wrote:
I have a PostgreSQL feature request:
Report the maximum size of a variable length string from the server.
Surely, we cannot be the only people who will need this information. If
(for example) someone wants to bind to a grid, then the maximum size has
to be known in
-Original Message-
From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
Sent: Monday, June 11, 2007 3:29 PM
To: Dann Corbit
Cc: Alvaro Herrera; Gregory Stark; pgsql-hackers@postgresql.org; Larry
McGhaw
Subject: Re: [HACKERS] Selecting a constant question
On Mon, Jun 11, 2007 at
Dann Corbit [EMAIL PROTECTED] writes:
These two calls make our remote queries via libpq about twice as fast on
average.
And, perhaps, cause even greater factors of degradation in other
scenarios (not to mention the possibility of complete failure on some
platforms). You haven't provided nearly
Dann Corbit wrote:
If the server bound the data as UNICODE, then it will tell me
UNICODE(3). I know how big this will be.
In the worst case scenario it will fit in 3*4 = 12 bytes.
If the server is built without UNICODE enabled, then it will definitely
fit in 3 bytes.
Unless it's some
Dann Corbit [EMAIL PROTECTED] writes:
To be honest, the concept that a widget requires a constant that can't
be changed later is also a bit odd.
Not when the data itself is a constant that cannot be changed.
Surely this case is not sufficiently important to justify designing
your entire
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Monday, June 11, 2007 3:41 PM
To: Dann Corbit
Cc: pgsql-hackers@postgresql.org; Larry McGhaw
Subject: Re: [HACKERS] Got no response last time on setsockopt post,
so I
thought I would reiterate.
Dann Corbit [EMAIL
-Original Message-
From: Alvaro Herrera [mailto:[EMAIL PROTECTED]
Sent: Monday, June 11, 2007 3:44 PM
To: Dann Corbit
Cc: Tom Lane; Gregory Stark; Martijn van Oosterhout; pgsql-
[EMAIL PROTECTED]; Larry McGhaw
Subject: Re: [HACKERS] Selecting a constant question
Dann Corbit
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Monday, June 11, 2007 3:50 PM
To: Dann Corbit
Cc: Martijn van Oosterhout; Alvaro Herrera; Gregory Stark; pgsql-
[EMAIL PROTECTED]; Larry McGhaw
Subject: Re: [HACKERS] Selecting a constant question
Dann Corbit
On Mon, 11 Jun 2007, Dann Corbit wrote:
These two calls make our remote queries via libpq about twice as fast on
average.
Can you comment a bit on what your remote queries are typically doing?
You'll need to provide at least an idea what type of test case you're
seeing the improvement on
-Original Message-
From: Greg Smith [mailto:[EMAIL PROTECTED]
Sent: Monday, June 11, 2007 4:09 PM
To: Dann Corbit
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Got no response last time on setsockopt post,
so I
thought I would reiterate.
On Mon, 11 Jun 2007, Dann Corbit
Dann Corbit wrote:
However, I won't twist your arm. I just wanted to be sure that those at
the PostgreSQL organization were aware of this simple trick. Our
products run on:
Aix
BeOS
Hpux
Linux (everywhere, including mainframe zLinux)
MVS
SunOS
Solaris
OpenVMS Alpha
OpenVMS VAX
OpenVMS
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: Monday, June 11, 2007 4:35 PM
To: Dann Corbit
Cc: Tom Lane; pgsql-hackers@postgresql.org; Larry McGhaw
Subject: Re: [HACKERS] Got no response last time on setsockopt post,
so I
thought I would reiterate.
Dann
I think perhaps we have lost sight of the main issue:
1) libpq can properly describe the maximum internal data size of any
numeric or char column in a table via Pqfsize
2) libpq can properly describe the maximum internal data size of any
varchar column via Pqfmod
3) libpq can properly describe
I think perhaps we have lost sight of the main issue:
1) libpq can properly describe the maximum internal data size of any
numeric or char column in a table via Pqfsize
2) libpq can properly describe the maximum internal data size of any
varchar column via Pqfmod
3) libpq can properly describe
On Mon, 11 Jun 2007, Larry McGhaw wrote:
I think perhaps we have lost sight of the main issue:
2) libpq can properly describe the maximum internal data size of any
varchar column via Pqfmod
SELECT cola || colb FROM tab;
3) libpq can properly describe the maximum internal data size of any
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Kris Jurka
Sent: Monday, June 11, 2007 5:04 PM
To: Larry McGhaw
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Selecting a constant question
On Mon, 11 Jun 2007, Larry
Larry McGhaw wrote:
4) libpq **cannot** describe the maximum internal data size of a char or
varchar constant!
Example: select '123' from any table
This is clearly a bug or serious oversight in libpq that should be
addressed.
The database *knows* this size of the char constant (obviously),
Dann Corbit [EMAIL PROTECTED] writes:
May I suggest:
http://www-didc.lbl.gov/TCP-tuning/setsockopt.html
http://www.ncsa.uiuc.edu/People/vwelch/net_perf/tcp_windows.html
I poked around on those pages and almost immediately came across
http://www.psc.edu/networking/projects/tcptune/
which
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Andrew Dunstan
Sent: Monday, June 11, 2007 5:12 PM
To: Larry McGhaw
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Selecting a constant question
Larry McGhaw wrote:
4)
Larry McGhaw [EMAIL PROTECTED] writes:
I think perhaps we have lost sight of the main issue:
1) libpq can properly describe the maximum internal data size of any
numeric or char column in a table via Pqfsize
2) libpq can properly describe the maximum internal data size of any
varchar column
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Monday, June 11, 2007 5:12 PM
To: Dann Corbit
Cc: pgsql-hackers@postgresql.org; Larry McGhaw
Subject: Re: [HACKERS] Got no response last time on setsockopt post,
so I
thought I would reiterate.
Dann Corbit [EMAIL
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Monday, June 11, 2007 5:32 PM
To: Larry McGhaw
Cc: Alvaro Herrera; Dann Corbit; Gregory Stark; Martijn van
Oosterhout;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Selecting a constant question
Larry McGhaw
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Monday, June 11, 2007 3:35 PM
To: Dann Corbit
Cc: Gregory Stark; Martijn van Oosterhout;
pgsql-hackers@postgresql.org;
Larry McGhaw
Subject: Re: [HACKERS] Selecting a constant question
Dann Corbit [EMAIL PROTECTED]
Andrew Dunstan wrote:
The CSVlog pipe is a separate pipe from the stderr pipe. Anything that
goes to stderr now will continue to go to stderr, wherever that is.
I like this scheme for a couple of reasons:
. it will include the ability to tell the real end of a message
. it will let us
As far as I am aware these statements are true. If you have a specific example
you could provide to the contrary that would be interesting.
Even if there are such conditions it does not change the fact that libpq and/or
postgresql is deficient in this area.
For any query, the database
Ühel kenal päeval, E, 2007-06-11 kell 13:38, kirjutas Dann Corbit:
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Monday, June 11, 2007 1:32 PM
To: Dann Corbit
Cc: Gregory Stark; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Selecting a constant
Ühel kenal päeval, E, 2007-06-11 kell 22:11, kirjutas Larry McGhaw:
As far as I am aware these statements are true. If you have a
specific example you could provide to the contrary that would be
interesting.
Even if there are such conditions it does not change the fact that
libpq and/or
-Original Message-
From: Hannu Krosing [mailto:[EMAIL PROTECTED]
Sent: Monday, June 11, 2007 8:42 PM
To: Dann Corbit
Cc: Tom Lane; Gregory Stark; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Selecting a constant question
Ühel kenal päeval, E, 2007-06-11 kell 13:38, kirjutas
-Original Message-
From: Hannu Krosing [mailto:[EMAIL PROTECTED]
Sent: Monday, June 11, 2007 10:43 PM
To: Larry McGhaw
Cc: Tom Lane; Alvaro Herrera; Dann Corbit; Gregory Stark; Martijn van
Oosterhout; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Selecting a constant question
71 matches
Mail list logo
