Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> It seems bootstrap parser(bootparse.y) does not accept partial index
> definitions. Is there any reason for this?
Why should it? The boot parser need handle only a minimal set of
operations. Why is there any need to handle partial indexes there?
As per earlier discussion, I'm working on the hot backup issues as part
of the PITR support. While I was looking at the buffer manager and the
relcache/MyDb issues to figure out the best way to work this, it
occurred to me that PITR will introduce a big problem with the way we
handle local relatio
I have a need for relation synonyms in PostgreSQL. I don't see it in
7.2.1 but the catalog seems to be able to support it more or less.
Here's what I intend to do:
1) Create a duplicate record in pg_class for the base table information
but with the relname set to the synonym name.
2) Duplicat
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
The code comes from a project in which I needed to import from Oracle
export files into PostgreSQL. I determined the export file format and
created a parser class. Since the INSERT syntax in Oracle export files
is based on a parse/bind/execute model, I created second module which
implements a
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 i
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
> > 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
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 inter
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]]
{
[@
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;
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, To
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
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
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 dev
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 m
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 connections.
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 ...;
> >
> > > EX
On Sun, 21 Jul 2002, Tom Lane wrote:
> Oleg Bartunov <[EMAIL PROTECTED]> writes:
> > We are about to submit brand bew contrib/ltree module
> > (first draft of documetation is available from
> > http://www.sai.msu.su/~megera/postgres/gist/ltree/)
> > and I have a question what version to submit -
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 t
"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 thi
[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
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
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
usersand developers groups.
Regards,Samuel Sutjiono_ Expand your
wireless world with Arkdom PLUS http:
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
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 a
26 matches
Mail list logo
