Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I don't think we should care too much about indexes. We can rebuild
> > them...but losing heap sectors means *data loss*.
>
> If you're so concerned about *data loss* then none of this will be
> acceptable to you at all. We are talking
This has been covered before, but to reiterate: why would you need this?
Any application worth its salt should be tracking which statements it
has already prepared (after all, they cannot span connections). Seems
a waste of resources to make a separate call to the database for
information you shou
On Fri, 15 Jul 2005, Marko Kreen wrote:
> [buildfarm machine dragonfly]
>
> On Tue, Jul 12, 2005 at 01:06:46PM -0500, Kris Jurka wrote:
> > Well the buildfarm machine kudu is actually the same machine just building
> > with the Sun compiler and it works fine. It links all of libz.a into
> >
David Wheeler <[EMAIL PROTECTED]> writes:
> 8.0.3 is working great for me on Mac OS X Tiger, but I do get a
> segfault every time I exit pssql:
> psql(7466) malloc: *** error for object 0x1806600: incorrect checksum
> for freed object - object was probably modified after being freed,
> break
I am totally confused by your response and Luke's. I think we might be
talking completely at cross purposes. My original question had nothing
to do with the COPY patch.
cheers
andrew
Ayush Parashar wrote:
Andrew, Luke,
As pointed by Luke, the reason for using mb regression suite (src/tes
This may sound silly, but any chance we could change autovacuum_* GUC
variables to be vacuum_auto_* instead?
This way when you issue a SHOW ALL, all of the vacuum related parameters
would be in the same place.
--
---(end of broadcast)---
TIP 9: In
Andrew, Luke,
As pointed by Luke, the reason for using mb regression suite (src/test/mb),
is to consolidate all similar kinds of multi-byte/client encoding tests at
one place.
Thanks,
Ayush
On 7/15/05 1:36 PM, "Luke Lonergan" <[EMAIL PROTECTED]> wrote:
>
> Andrew,
>
>> Good. So should we roll
Luke Lonergan wrote:
Andrew,
Good. So should we roll this up into the standard regression suite? Why
are these tests separate? Is it just that they need a UTF8 encoded db
rather than an SQL-ASCII encoded db?
I think that was the idea - the src/test/mb kit was already there and was
Andrew,
> Good. So should we roll this up into the standard regression suite? Why
> are these tests separate? Is it just that they need a UTF8 encoded db
> rather than an SQL-ASCII encoded db?
I think that was the idea - the src/test/mb kit was already there and was
designed to create the UTF8 d
[buildfarm machine dragonfly]
On Tue, Jul 12, 2005 at 01:06:46PM -0500, Kris Jurka wrote:
> Well the buildfarm machine kudu is actually the same machine just building
> with the Sun compiler and it works fine. It links all of libz.a into
> libpgcrypto.so while gcc refuses to.
I googled a bit a
At 2005-07-15 17:17:01 +0200, [EMAIL PROTECTED] wrote:
>
> I needed prepared queries in plperl, but there's none, so I baked
> a patch that defines two extra perl functions, spi_prepare and
> spi_exec_prepared
Oh. I've been working on the same functionality this week following a
conversation with
Hi,
I needed prepared queries in plperl, but there's none, so I baked a patch that
defines two extra perl functions, spi_prepare and spi_exec_prepared, and it
seems to work more-less ok. The patch is here,
http://www.karasik.eu.org/misc/plperl.diff
but it's not in any way a final patch; havin
On Fri, 15 Jul 2005, Hannu Krosing wrote:
> What comes to Toms's May 20 argument that people would be surprised when
> they select form a table whith check(i>0) constraint and get out i<0
> then I think this is a question of education.
I potentially disagree. What are we trying to model here? Sys
Good. So should we roll this up into the standard regression suite? Why
are these tests separate? Is it just that they need a UTF8 encoded db
rather than an SQL-ASCII encoded db?
cheers
andrew
Luke Lonergan wrote:
They should be completely portable (provided the script in src/test/mb runs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> The use case is when you want to prepare a query, but only if it's not
> already prepared on that connection.
This has been covered before, but to reiterate: why would you need this?
Any application worth its salt should be tracking which statemen
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Would it be useful to have a pg_get_prepared(name) function that returns
> true or false depending on whether or not there is a prepared query of
> that name?
This has been discussed as something needed at the protocol level, not
a SQL functi
On Fri, 2005-07-15 at 11:10 +0300, Hannu Krosing wrote:
> Bruce: could you change this TODO item
>
> o Prevent child tables from altering constraints like CHECK that were
> inherited from the parent table
>
> to
>
> o Prevent new child tables from inheriting constraints defined on
>
Bruce: could you change this TODO item
o Prevent child tables from altering constraints like CHECK that were
inherited from the parent table
to
o Prevent new child tables from inheriting constraints defined on
parents with keyword ONLY:
alter table ONLY t add constraint c check
On 7/15/05, Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
> > You're mentioning about PHP PostgreSQL API, right?
>
> No, I'm talking about a PostgreSQL backend function.
Sorry, when you give a name like pg_get_prepared() (which is used in
PHP PostgreSQL API functions), I thought it's for PHP
Christopher Kings-Lynne wrote:
Would it be useful to have a pg_get_prepared(name) function that returns
true or false depending on whether or not there is a prepared query of
that name?
From the TODO:
* Allow pooled connections to list all prepared queries
So this has been raised before.
-N
On R, 2005-07-15 at 00:24 +0300, Hannu Krosing wrote:
> There is a good fundamental reason why we dont let people drop columns
> from children or to add them to parent ONLY: if we did not, then there
> would be no way to query from the hierarchy.
>
> I can't see any such reason for forbidding dro
Volkan YAZICI wrote:
Hi,
On 7/15/05, Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
Would it be useful to have a pg_get_prepared(name) function that returns
true or false depending on whether or not there is a prepared query of
that name?
(You're mentioning about PHP PostgreSQL API, r
Hi,
On 7/15/05, Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
> Would it be useful to have a pg_get_prepared(name) function that returns
> true or false depending on whether or not there is a prepared query of
> that name?
(You're mentioning about PHP PostgreSQL API, right?) I couldn't see
a
23 matches
Mail list logo
