> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > I notice that we're still dumping CHECK constraints as part of the
CREATE
> > TABLE statement, and not as an ALTER TABLE statement after the data has
been
> > loaded.
>
> > Should we move it to after the data for speed purposes, like we h
what cvs version are you working with?
Dave
On Wed, 2003-02-26 at 01:11, Tom Lane wrote:
> Dave Cramer <[EMAIL PROTECTED]> writes:
> > Can someone point me to the documentation for the new autocommit mode
> > behaviour, I must be doing something wrong
>
> Must be :-(. I repeated your example as
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> I notice that we're still dumping CHECK constraints as part of the CREATE
> TABLE statement, and not as an ALTER TABLE statement after the data has been
> loaded.
> Should we move it to after the data for speed purposes, like we have with
> a
Hi guys,
I notice that we're still dumping CHECK constraints as part of the CREATE
TABLE statement, and not as an ALTER TABLE statement after the data has been
loaded.
Should we move it to after the data for speed purposes, like we have with
all other constraints?
Chris
--
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Were the pgattribute.attstorage and pg_type.typstorage fields available in
> 7.1?
Yes, but typstorage did not appear in 7.0, which you're also supposed to
think about if you're hacking pg_dump. (AFAICT attstorage was always
'p' in 7.0.)
> A
Hi Guys,
Were the pgattribute.attstorage and pg_type.typstorage fields available in
7.1?
Also, if they existed in 7.2, but the ALTER TABLE/SET STORAGE command didn't
exist, should I still dump it if they are dumping a 7.2 database?
Chris
---(end of broadcast)--
Dave Cramer <[EMAIL PROTECTED]> writes:
> Can someone point me to the documentation for the new autocommit mode
> behaviour, I must be doing something wrong
Must be :-(. I repeated your example as best I could, and it behaved
as expected.
<< session 1 >>
regression=# set autocommit=off;
SET
reg
Can someone point me to the documentation for the new autocommit mode
behaviour, I must be doing something wrong
I do a set autocommit=off;
begin;
create table foo ...
insert into foo
end;
and if I look for the table foo from another connection, it isn't there?
my source tree is REL7_3_STABLE
Example 7-5 in the User's Guide is also outdated, because there is now a
function substr for bytea, so the mechanics the example tries to
illustrate are a tad more complicated. New example requested.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)-
On Tue, Feb 25, 2003 at 07:34:12PM +, Darko Prenosil wrote:
>
> Unfortunately it is application written in QT library that should work on
> Windows too, but I'll take a look, I'm sure I can learn something from it !
Well, libpqxx also runs on Windows but it takes a decent compiler (e.g.
Visua
On Tuesday 25 February 2003 17:14, Jeroen T. Vermeulen wrote:
> On Tue, Feb 25, 2003 at 05:55:59PM +, Darko Prenosil wrote:
> > I am trying to create client buffer that will show only records that are
> > needed by application(visible). Data should be send to client in "pages",
> > not all
On Tue, Feb 25, 2003 at 05:55:59PM +, Darko Prenosil wrote:
>
> I am trying to create client buffer that will show only records that are
> needed by application(visible). Data should be send to client in "pages", not
> all the data at once. The idea is not to query for data that are alre
On Tue, 2003-02-25 at 03:59, Christoph Haller wrote:
> for (CmdIndex = start_index; CmdIndex < nRows; CmdIndex++)
> {
> sprintf(CmdLine,
> "INSERT INTO AArray_Values ( Primary_Key, List_Pointer,\
>Parameter_Name, Parameter_Code,\
> Dim_Pointer, File_Pointer, Source_Type )\
-- Forwarded Message --
Subject: Re: [HACKERS] I cant find it or I'm just lazy ?
Date: Tue, 25 Feb 2003 17:51:13 +
From: Darko Prenosil <[EMAIL PROTECTED]>
To: Christoph Haller <[EMAIL PROTECTED]>
On Tuesday 25 February 2003 13:04, Christoph Haller wrote:
> > On Tuesday 25
Okay guys, i've been a bit tight of time recently to move forward on
this, but I plan to do a small amount of work on the patches to clean
them up so they can be merged into the sources.
I'll also add a README to document what will need to be fudged in the
makefile to get it building. Hopefully th
On Mon, Feb 24, 2003 at 09:23:38PM +0530, Shridhar Daithankar<[EMAIL PROTECTED]> wrote:
> I was just wondering.The patches for making ecpg thread safe that were
> floating around few days back, are they going to make in any near future
> releases?
I sure hope so. AFAIK there are some small issue
On Tue, Feb 25, 2003 at 02:04:50PM +0100, Christoph Haller wrote:
>
> Anyway, you may MOVE until 0 instead of FETCH, or use the COUNT()
> function on the query to learn about the number of rows to be returned.
Hmm... Wouldn't the reliability of a count() depend on the isolation
level?
OTOH the p
On Tue, Feb 25, 2003 at 08:13:27AM -0500, mlw wrote:
> things about the PostgreSQL core team that troubles me is a fairly
> arbitrary feature selection process.
[. . .]
> In Open Source, the attitude should not be "do we want this feature?"
> but "can we add/keep this without affecting anythin
I don't understand why you would want to remove a working feature. Even
if they are features which you do not like, why remove them? One of the
things about the PostgreSQL core team that troubles me is a fairly
arbitrary feature selection process.
It seems a feature has to be "liked" by someone
>
> On Tuesday 25 February 2003 09:28, Christoph Haller wrote:
> > > On Mon, Feb 24, 2003 at 07:53:05PM +, Darko Prenosil wrote:
> > > > I need two answers I did not find in documentation :
> > > > How can I get exact number of rows in DECLARED CURSOR ?
> > > > OK, I can FETCH until NULL, b
> > > How can I get information is TRANSACTION already started ?
> I did not mean 'TRANSACTION ISOLATION LEVEL', but 'TRANSACTION LEVEL'
!
> OK, it is bad construction - my fault !
> What I meant is : IS-TRANSACTION-ALREADY-STARTED ?
> I used 'TRANSACTION LEVEL' because I saw that Bruce is working
http://www.theinquirer.net/?article=7966
On Mon, 2003-02-24 at 22:25, [EMAIL PROTECTED] wrote:
> > After failing to make Itanium competitive, Intel is now downplaying
> > 64-bit CPU's. Of course, they didn't think that until Itanium failed.
> > Here is the slashdot story:
> > http://slashdot.o
On Tuesday 25 February 2003 09:28, Christoph Haller wrote:
> > On Mon, Feb 24, 2003 at 07:53:05PM +, Darko Prenosil wrote:
> > > I need two answers I did not find in documentation :
> > > How can I get exact number of rows in DECLARED CURSOR ?
> > > OK, I can FETCH until NULL, but this does
On Tuesday 25 February 2003 09:28, Christoph Haller wrote:
> > On Mon, Feb 24, 2003 at 07:53:05PM +, Darko Prenosil wrote:
> > > I need two answers I did not find in documentation :
> > > How can I get exact number of rows in DECLARED CURSOR ?
> > > OK, I can FETCH until NULL, but this does
>
> On Mon, Feb 24, 2003 at 07:53:05PM +, Darko Prenosil wrote:
> > I need two answers I did not find in documentation :
> > How can I get exact number of rows in DECLARED CURSOR ?
> > OK, I can FETCH until NULL, but this does not fits my needs !
You may want to use FETCH ALL, otherwise wha
>
> On Mon, 2003-02-24 at 07:22, Christoph Haller wrote:
> > I've noticed subsequent executions of the same insert command are
slow.
> > I've searched the list archives for this matter and found several
> > entries
> > related, including suggestions how to speed up.
> > The standard answer from the
>
> > The key word REPEATED directs INGRES to encode the INSERT and save
its
> > execution plan when it is first executed. This encoding can account
for
> > significant performance improvements on subsequent executions of the
> > same INSERT.
>
> > What do you others think of it?
>
> You can do th
27 matches
Mail list logo
