On Mon, 21 Mar 2005, Tom Lane wrote:
> Awhile back I wrote:
> > Basically what I am thinking is that we have all the infrastructure
> > today to solve the OUT-parameter problem, it's just not wrapped up in
> > an easy-to-use package.
>
>
> Note that the result type is RECORD; we won't explicitly
Neil Conway wrote:
AndrewSN pointed out on IRC that ALTER TABLE ... ADD FOREIGN KEY and
CREATE TRIGGER both acquire AccessExclusiveLocks on the table they are
adding triggers to (the PK table, in the case of ALTER TABLE). Is this
necessary? I don't see why we can't allow SELECT queries on the ta
AndrewSN pointed out on IRC that ALTER TABLE ... ADD FOREIGN KEY and
CREATE TRIGGER both acquire AccessExclusiveLocks on the table they are
adding triggers to (the PK table, in the case of ALTER TABLE). Is this
necessary? I don't see why we can't allow SELECT queries on the table to
proceed whi
Tom Lane <[EMAIL PROTECTED]> writes:
> > I would have expected the return value to be an extra column added to the
> > record.
>
> I'd prefer not to do that, because having a "return type" that's
> different from the true return type of the function (ie the RECORD)
> is going to cause untold amo
Hi,
If I use PQgetCopyData, PQputCopyData and PQputCopyEnd against a v2
protocol backend, will it work?
I see no mention of it in the docs...
Chris
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
"Tom Lane" <[EMAIL PROTECTED]> writes
>
> We already have the ability to issue custom messages in assign_hooks,
> and I think that's sufficient in practice.
Yes, I agree this is already sufficient - seems we need to remove that TODO
item in the list.
>
> A bigger problem with making cross-variab
Should psql and pg_dump be upgraded to use the new v3 protocol copy
functions if they are available, as they are currently using the
deprecated API.
Chris
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Gavin Sherry <[EMAIL PROTECTED]> writes:
> I think that not specifying OUT parameters when invoking a function is a
> little of confusing but it gives us a lot: its much easier to develop
> since we don't have to add a stack of infrastructure for host variables,
> for one.
Also, it doesn't stop us
On Tue, 22 Mar 2005, Christopher Kings-Lynne wrote:
> >>ANSI SQL allows at most one OUT parameter for a function (which can be
> >>used instead of having the function return a value via the usual means).
> >
> > OK, so that answers my question above: a single OUT parameter should be
> > equated to
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Shouldn't you have the spec in one hand while designing this feature? :D
Actually, plpgsql generally pays more attention to Oracle than the spec ;-)
The truth though is that I'd missed that aspect of SQL99, and now that I
have read it I don't
ANSI SQL allows at most one OUT parameter for a function (which can be
used instead of having the function return a value via the usual means).
OK, so that answers my question above: a single OUT parameter should be
equated to an ordinary return value, not a RECORD, so as to emulate this
aspect of
Gavin Sherry <[EMAIL PROTECTED]> writes:
>> Tom Lane <[EMAIL PROTECTED]> writes:
>>> (When there is just one, should the default be to return that type
>>> rather than a one-column RECORD?)
> ANSI SQL allows at most one OUT parameter for a function (which can be
> used instead of having the functi
On Tue, 21 Mar 2005, Greg Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > The generic thing: you can write OUT and INOUT parameters in CREATE
> > FUNCTION. If you do, you can omit the RETURNS clause, in which case the
> > result type of the function is implicitly RECORD; or you can spec
Greg Stark <[EMAIL PROTECTED]> writes:
> Do other databases not allow you to specify a return value in addition to the
> OUT and INOUT parameters?
Oracle discourages OUT parameters in a function, so PL/SQL at least
shouldn't be a big source of cases where that's a problem.
> I would have expected
On Sun, 2005-03-20 at 12:28 -0500, Tom Lane wrote:
> > Removing FlushRelationBuffers in those circumstances will save a scan of
> > shared_buffers, but will it save I/O? Perhaps not, but I care more about
> > the O(N) operation on shared_buffers than I do about the I/O.
>
> Realistically, wasted I
On Mon, Mar 21, 2005 at 02:25:47PM -0500, Tom Lane wrote:
> A possible future extension is to add some sort of direct procedure call
> syntax in plpgsql. Right now, you'd need to write something like
> select into x,y,z from foo(a,b,c);
> to call a function with IN parameters a,b,c and get b
Tom Lane <[EMAIL PROTECTED]> writes:
> The generic thing: you can write OUT and INOUT parameters in CREATE
> FUNCTION. If you do, you can omit the RETURNS clause, in which case the
> result type of the function is implicitly RECORD; or you can specify
> RECORD explicitly; or you can specify SETOF
Awhile back I wrote:
> Basically what I am thinking is that we have all the infrastructure
> today to solve the OUT-parameter problem, it's just not wrapped up in
> an easy-to-use package.
Here is a more fully fleshed-out proposal. The basic goal that I'm
aiming at is to be able to use OUT-parame
Hello,
O.k. this is the wrong query, but it still shows the odd slowness. I am
going to test the full dataset on FC2 and see what happens.
J
On Mon, 2005-03-21 at 10:58 -0800, Joshua D. Drake wrote:
> Hello,
>
> O.k. here is a great one for you. Here are some further comparisons:
>
> 8.0.1 FC3
Hello,
O.k. here is a great one for you. Here are some further comparisons:
8.0.1 FC3 64bit:
foo=# explain analyze SELECT t.topic_id, t.topic_title, t.topic_status,
t.topic_replies, t.topic_time, t.topic_type, t.topic_vote,
t.topic_last_post_id, f.forum_name, f.forum_status, f.forum_id,
f.auth_v
On Sunday 20 March 2005 13:24, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > know that it doesn't match reality at this point. We could have someone
> > update it and then generate it out of cvs onto the website, but it really
> > seems like the kind of thing that should live in t
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> In this design, our ability to check the conflicting SET or give suggestions
> is contributed by SQL's functionality. This is good I think.
This is out of the question, because we have to be able to execute SET
in environments where we don't have datab
This an item in the TODO list. But I am not sure how severe the problem is.
In my understanding, there are not so many conflicts but we may want to give
some hints to users of how to set proper GUC variables. For instance, if we
find "debug_print_parse" is set, we will suggest setting
"debug_pretty
On Thu, Mar 17, 2005 at 05:22:41AM +, Christopher Browne wrote:
> What strikes me as being a useful approach would be to set up an
> LRU-ordered (or perhaps unordered) queue of pages that have had tuples
> "killed off" by DELETE or UPDATE.
>From http://www.postgresql.org/docs/faqs.TODO.html :
24 matches
Mail list logo
