On Fri, Aug 15, 2008 at 08:47:49PM -0700, Bosco Rama wrote:
> [22245]: ecpg_execute line 13256: QUERY: set search_path to $1 with 1
> parameter on connection ecpgconn
> [22245]: ecpg_execute line 13256: using PQexecParams
> [22245]: free_params line 13256: parameter 1 = myschema
> [22245]: ecpg_
While noticing this one, I also noticed we don't remove probes.h when we
do "clean" in the msvc setup. We probably should, no?
//Magnus
Original Message
Subject: [COMMITTERS] pgsql: probes.h is generated from probes.d, not
pg_trace.d.
Date: Sat, 16 Aug 2008 12:42:27 + (UTC)
Bruce Momjian wrote:
> Magnus Hagander wrote:
>>> To address Magnus' specific question, right now we store the pg_hba.conf
>>> tokens as strings in the postmaster. I am fine with storing them in a
>>> more native format and throwing errors for values that don't convert.
>>> What would concern me
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Other than that, it moves code around to do the parsing in the
> postmaster and the maching in the backend.
How does that work in EXEC_BACKEND environments?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hack
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> or just use := operator?
You're still commandeering an operator name that wasn't reserved before.
This one doesn't even have the feeble excuse of being Oracle-compatible.
regards, tom lane
--
Sent via pgsql-hackers mailing li
Michael Meskes <[EMAIL PROTECTED]> writes:
> Without checking the sources it seems as if PQexecParams is not able to
> handle a parameter in a set command. Can anyone confirm this?
The backend only supports parameters in plannable statements, ie
SELECT/INSERT/UPDATE/DELETE. (Possibly DECLARE CUR
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Other than that, it moves code around to do the parsing in the
>> postmaster and the maching in the backend.
>
> How does that work in EXEC_BACKEND environments?
(Not tested yet, still on my TODO, but still)
It will parse the file
On Saturday 16 August 2008 09:38:41 Pavel Stehule wrote:
> because you have to write labels, where labels are equal with column
> names. I would to add same comfort like SQL/XML functions.
Just a thought: You might be able to design this in some way to work on top of
named parameter calling. Def
On Sat, 2008-08-16 at 08:44 +0200, Pavel Stehule wrote:
> Hello
> >> "value AS name", on the other hand, accomplishes the same in a more
> >> SQL-looking fashion with no new reserved word (since AS is already
> >> fully reserved).
> >
> > would it be more natural / SQL-like to use "value AS name"
> "Magnus" == Magnus Hagander <[EMAIL PROTECTED]> writes:
[snip]
I'm looking (at Magnus' suggestion) at implementing this.
There appears to be only one significant obstacle; since the query
cancel message is received _after_ forking a new backend, there has to
be some mechanism for recordin
Hi
We need plan invalidation fix in 8.3 also at least it would make migrating
from 8.2 to 8.3 much more attractive.
Currenlty we are having problems related to plan invalidation couple of
times per week (mainly we have to let developers change their code before we
release it into live databases bu
Andrew Gierth wrote:
> There appears to be only one significant obstacle; since the query
> cancel message is received _after_ forking a new backend, there has to
> be some mechanism for recording the new value of N on success. This
> is obviously fairly easy in the EXEC_BACKEND case, but it seem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 12 août 08 à 18:41, Bruce Momjian a écrit :
Are you proposing that we should introduce our own packaging system
for
such add-on components? Like CP(g)AN (which has been proposed
before..)?
Yes, pretty much. I imagine some kind of web int
On Aug 15, 2008, at 1:00 AM, Ryan Bradetich wrote:
Here is the first pass at the unsigned data type I have been
working on.
I am planning on adding these to the September 2008 commitfest wiki
page.
The unsigned data type is not targeted for core, but for the uint
PgFoundry project.
Is t
On Aug 15, 2008, at 1:20 PM, Hannu Krosing wrote:
"value AS name", on the other hand, accomplishes the same in a more
SQL-looking fashion with no new reserved word (since AS is already
fully reserved).
would it be more natural / SQL-like to use "value AS name" or "name AS
value" ?
IMHO, *nat
I came across this bug tonight:
-- Function: pre_delete_main()
CREATE FUNCTION pre_delete_main()
RETURNS TRIGGER AS
$BODY$BEGIN
DROP TABLE bug_referring_table;
RETURN OLD;
END;$BODY$
LANGUAGE 'plpgsql' VOLATILE
COST 100;
-- Table: bug_referenced_table
CREATE TABLE bug_referenced_table
(
"Dan Eloff" <[EMAIL PROTECTED]> writes:
> It seems the trigger list is calculated once, and does not reflect
> changes made by triggers in that list. Are there good reasons for
> doing that? Should that behavior be changed?
Yes. No. Don't hold your breath on this being considered a bug.
"Asko Oja" <[EMAIL PROTECTED]> writes:
> Is it possible to get it into some official 8.3.x release
This is not the kind of patch we put into stable branches.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Andrew Gierth wrote:
>> 2. The server accepts either the old-style or the secure cancel
>> request from the client, but doesn't allow old-style requests
>> once a valid secure request has been seen.
> Hmm, I think there should be a way to turn off accep
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
>> Andrew Gierth wrote:
>>> 2. The server accepts either the old-style or the secure cancel
>>> request from the client, but doesn't allow old-style requests
>>> once a valid secure request has been seen.
>> Hmm, I think there should be a w
2008/8/16 Decibel! <[EMAIL PROTECTED]>:
> On Aug 15, 2008, at 1:20 PM, Hannu Krosing wrote:
>>>
>>> "value AS name", on the other hand, accomplishes the same in a more
>>> SQL-looking fashion with no new reserved word (since AS is already
>>> fully reserved).
>>
>> would it be more natural / SQL-li
21 matches
Mail list logo
