Hi guys,
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?
Perhaps we could have a way of checking the parameter types of it as well?
(Also no-one replied to my PQescapeIdentifier
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
any
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,
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
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.
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 too.
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
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
parents
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 function.
-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
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
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(i0) constraint and get out i0
then I think this is a question of education.
I potentially disagree. What are we trying to model here? Systems
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;
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
[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 and
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
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, 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 this up
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:
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
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 at
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
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
23 matches
Mail list logo
