Consider:
create function a(anyrecord) returns anyrecord;
create function b(int4) returns anyrecord;
select a(b(2));
for my task I need little different form :-(
create function a(..) returns setof tables
but SQL2003 needs type table, and this can be solution
___
On 2005-11-19, Grzegorz Jaskiewicz <[EMAIL PROTECTED]> wrote:
> Wildcards cause things not to work as they should
>
> consider everything in [] brackets to be a possible choice and those
> three:
>
> a = 1.2.3.4
> b = 1.[2,3].3.4
> c = 1.3.3.4
>
> a = b, b = c, but a <> c, I was told that because
Tom Lane wrote:
> Martijn van Oosterhout writes:
> > So, kill a few birds with one stone. Any thoughts?
>
> I don't think any of this will actually work :-(. There's too much code
> that assumes that all the tuples returned by a query are alike, and I
> for one don't feel like trying to find and
Jonah,
> Do you have an 8.1 patch for this or only the 8.0.x?
Nope, this is Satoshi's code, ask him.
BTW, I'm not sure that the DBT2 test is ideal for this sort of thing anyway.
We really need a few tests that are heavier on UPDATEs than on INSERTS.
Maybe a few data warehousing-style merges.
Heikki,
> Could you post it to the list? I'd be interested to take a look, though
> I'm afraid don't have the time to work on it.
Yeah, I should put it up on pgFoundry. I'm not sure exactly where, though --
I don't want to launch a new project if it's not going to take off. Maybe
Bizgres.
-
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> In dbcommands.c::dropdb() there are these lines:
> /* Close pg_database, but keep exclusive lock till commit */
> heap_close(pgdbrel, NoLock);
> However, ISTM that if I return early from that function because the db
> doesn't exist I should re
In dbcommands.c::dropdb() there are these lines:
/* Close pg_database, but keep exclusive lock till commit */
heap_close(pgdbrel, NoLock);
However, ISTM that if I return early from that function because the db
doesn't exist I should release the lock immediately. Or is there
something I
On Sat, Nov 19, 2005 at 12:43:15PM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > So, kill a few birds with one stone. Any thoughts?
>
> I don't think any of this will actually work :-(. There's too much code
> that assumes that all the tuples returned by a query are alike, and I
>
Martijn van Oosterhout writes:
> So, kill a few birds with one stone. Any thoughts?
I don't think any of this will actually work :-(. There's too much code
that assumes that all the tuples returned by a query are alike, and I
for one don't feel like trying to find and fix it all. (Not all of it
I looked into this 8.1 bug reported by Alexey Beschiokov:
http://archives.postgresql.org/pgsql-bugs/2005-11/msg00192.php
The executive summary is: it looks like a kluge solution isn't hard,
but solving it in a more reasonable fashion is going to require some
significant API changes inside the backe
I've been thinking about this and wondered if this is a way to get it
done without too much work.
1. Create an "anyrecord" type to which any record type can be cast.
It's essentially a heaptuple with a tupledesc.
2. "anyrecord" is opaque to the parser, you cannot dereference it, only
output it or
i think if the protocol is enhanced again we should also consider adding
protocol level support for RESET CONNECTION.
i have sent this patch some time ago but i think it is not worth to do
the remaining protocol level changes (sql level support is finished) if
this is the only change on the pr
(CCed to the matview-devel mailing list)
On 11/19/05, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> I've been reading some papers on materialized views lately. Here's some
> interesting ones:
(snip)
You might want to take a look at the pages that I set up to track the
progress on my master's
On Sat, Nov 19, 2005 at 12:40:23PM +0100, Pavel Stehule wrote:
>
>
> >What do you mean? There are already 10 levels for elog, including five
> >levels of DEBUG. How many more do you want?
>
> sometimes I need show only some text. Now I get stack info.
> lighter elog ~ sending text, not. proc, st
What do you mean? There are already 10 levels for elog, including five
levels of DEBUG. How many more do you want?
sometimes I need show only some text. Now I get stack info.
lighter elog ~ sending text, not. proc, stack info.
> 2. multi result sets. This is necessery for support procedure
On Sat, Nov 19, 2005 at 11:07:58AM +0100, Pavel Stehule wrote:
> Hello
>
> Meybe is time for some changes. Maybe. I haven't courage for it. But maybe
> is good time for discussion. What I miss in protocol?
>
> 1. debug. support + other level for elog. Current elog is too heavy
> (sometimes)
W
Hello
Meybe is time for some changes. Maybe. I haven't courage for it. But maybe
is good time for discussion. What I miss in protocol?
1. debug. support + other level for elog. Current elog is too heavy
(sometimes)
2. multi result sets. This is necessery for support procedures in DB2,
MySQL
On Fri, 18 Nov 2005, Josh Berkus wrote:
Alvaro,
I guess there must be a query-rewriting mechanism for implementing
materialized views. With that in place we may be able to implement this
other thing ... Is anybody working on materialized views?
I have a bundle of academic code designed to
18 matches
Mail list logo
