Tom wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
That doesn't quite work, because then no ordinary user can define a cast
from some built-in type to his own type. What I'm thinking about is to
implement the USAGE privilege on types, and then you need to have that to
be allowed to
On Tuesday 23 July 2002 02:59, Joe Conway wrote:
Darren Ferguson wrote:
Not that i am aware of
On Tue, 23 Jul 2002, Dean Grubb wrote:
Hi,
Is it possible using pl/pgSQL functions to grab data from another
database or even another database on a different host.
You can with
I've finally
got around to try RAMDISK with PostgreSQL. The attached doccontains
the test results that I'd like to share with PostgreSQL's
usersanddevelopers groups.
Regards,Samuel Sutjiono_Expand your
wireless world with Arkdom
Interesting results. You didn't really offer much in how your system
was configured to use the ramdisk. Did you use it to simply store a
database on it? Was the entire database able to fit into available
memory even without the RAMDISK? Did you try only storing indicies on
the RAMDISK? There
[EMAIL PROTECTED] (Neil Conway) writes:
Regarding the syntax for EXECUTE, it occurs to me that it could be made
to be more similar to the PREPARE syntax -- i.e.
PREPARE foo(text, int) AS ...;
EXECUTE foo('a', 1);
(rather than EXECUTE USING -- the effect being that prepared statements
now
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
But you *didn't* make sure it would never be a problem.
Wasn't I looping until I found a unique name?
My point was that there could still be a conflict against a user column
that the user tries to create *later*. So it's illusory to think
On Tue, 2002-07-23 at 11:34, Tom Lane wrote:
[EMAIL PROTECTED] (Neil Conway) writes:
Regarding the syntax for EXECUTE, it occurs to me that it could be made
to be more similar to the PREPARE syntax -- i.e.
PREPARE foo(text, int) AS ...;
EXECUTE foo('a', 1);
(rather than EXECUTE
Rod Taylor wrote:
On Tue, 2002-07-23 at 11:34, Tom Lane wrote:
[EMAIL PROTECTED] (Neil Conway) writes:
Regarding the syntax for EXECUTE, it occurs to me that it could be made
to be more similar to the PREPARE syntax -- i.e.
PREPARE foo(text, int) AS ...;
EXECUTE foo('a', 1);
Hi,
We are moving to postgres from Oarcle. When we were with Oracle, we were
using a total of 160 connections(4 app servers each maintaining a pool of 40
connections). After moving to postgres we want to make it higher i.e make it
60 connections for each app server i.e a total of 240
On Tue, Jul 23, 2002 at 01:01:42PM -0700, Yuva Chandolu wrote:
Hi,
We are moving to postgres from Oarcle. When we were with Oracle, we were
using a total of 160 connections(4 app servers each maintaining a pool of 40
connections). After moving to postgres we want to make it higher i.e make
Hello,
pgaccess 0.98.8 weekly release 1 is available for download from the
pgaccess web site -
www.pgaccess.org
This version is the net effect of the effort started about April this year
for merging three large groups of patches accumulated by Bartus, Boyan and
Chris.
Since then the pgaccess
On Tue, 2002-07-23 at 20:42, Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
But you *didn't* make sure it would never be a problem.
Wasn't I looping until I found a unique name?
My point was that there could still be a conflict against a user column
that the user
Any chance you can work on save points/nested transactions? See
doc/TODO.detail/transactions for info. I can help explaining the ideas
in there.
---
Dhruv Pilania wrote:
Hi,
I am a new postgresql developer. needed
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Oleg Bartunov wrote:
On Sun, 21 Jul 2002,
Tom Lane wrote:
Marc Lavergne [EMAIL PROTECTED] writes:
never any mention of C++ (libpq++ excepted). So, at a risk of stating
the obvious (and I'm 99.99% sure I am), does backend code need to be
submitted as C even if it's for an entirely NEW module?
Backend code must be C; we do not
Mike Mascari wrote:
FWIW, Oracle uses EXECUTE to execute stored procedures. It is not apart
of the SQL language, but a SQL*Plus command:
EXECUTE my_procedure();
Also with Transact SQL (i.e. MSSQL and Sybase)
Syntax
Execute a stored procedure:
[[EXEC[UTE]]
{
Darko Prenosil wrote:
Before about 3 months I send to You pl/pgSql wrapper functions for libpq.
We agreed then, that merging it with dblink would be a good idea.
Meanwhile i used dblink and those functions and wrote some kind of
replication for my app.
Is there interest for such
My point was that there could still be a conflict against a user column
that the user tries to create *later*. So it's illusory to think that
making the name of a dropped column less predictable will improve
matters.
The simple (to describe, perhaps not to implement ;) way to resolve
Tatsuo Ishii wrote:
It seems bootstrap parser(bootparse.y) does not accept partial index
definitions. Is there any reason for this?
Probably just because we never needed them. We could add it, or just
create the index later in the initdb script. That later seems easier.
--
Bruce Momjian
Tatsuo Ishii wrote:
It seems bootstrap parser(bootparse.y) does not accept partial index
definitions. Is there any reason for this?
In private email with Tatsuo, I learned it is for the new loadable
encoding patch, and he wants to use the index from the syscache. The
reason for the partial
To expand on the Oracle implementation, the EXECUTE command in SQL*Plus
results in an anonymous pl/sql block (as opposed to a named procedure).
being sent over the wire such as the following:
begin
my_procedure();
end;
As mentioned in the previous post, the EXECUTE command is only a
SQL*Plus
21 matches
Mail list logo
