It seems bootstrap parser(bootparse.y) does not accept partial index
definitions. Is there any reason for this?
--
Tatsuo Ishii
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourE
> Yup, we need to figure out a way of preventing that. I've been thinking
> about adding an attisinherited column to pg_attribute, to mark columns
> that came from a parent table. Such a column could not be renamed or
> dropped except in a command that's recursed from the parent. (But what
> ab
Neil Conway wrote:
>On Sat, Jul 20, 2002 at 10:00:01PM -0400, Tom Lane wrote:
>
>
>>AFAICT, the syntax we are setting up with actual SQL following the
>>PREPARE keyword is *not* valid SQL92 nor SQL99. It would be a good
>>idea to look and see whether any other DBMSes implement syntax that
>>
On Sat, Jul 20, 2002 at 10:00:01PM -0400, Tom Lane wrote:
> AFAICT, the syntax we are setting up with actual SQL following the
> PREPARE keyword is *not* valid SQL92 nor SQL99. It would be a good
> idea to look and see whether any other DBMSes implement syntax that
> is directly comparable to the
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 create casts
Tom Lane writes:
> I looked through your CREATE CAST commit a little. Looks pretty good
> but I had a few suggestions/concerns.
>
> * The biggie is that I'm not satisfied with the permissions checking.
Me neither. I had sent a message earlier about this but it went
unnoticed, but I had to impl
> -Original Message-
> From: Dhruv Pilania [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, July 20, 2002 11:37 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: PITR and rollback
>
>
> Hi,
>
> I am a new postgresql developer. needed some help with wal/PITR. Ca
At 02:17 PM 7/20/02 +0900, Curt Sampson wrote:
>Have you tried it using the standard relational method of doing this?
>(I.e., you put the common fields in one table, and the extra fields in
>other tables, along with a foreign key relating the extra fields back
>to the main table.) That would more
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 want to deal with
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Hmmm...does this mean that there is any situation in which there would be a
> cascade delete of a _column_?
You bet. That's why we need DROP COLUMN done ;-)
> ie. If you drop the domain a column is using with the cascade option, will
> th
Hi,
I am a new postgresql developer. needed some help with wal/PITR. Can
someone working in this area answer my question?
(the email looks long but the question is simple :) )
I have been trying to implement undo of transactions using wal. i.e. given
a xid x, postgres can undo all operations of
Hello!
i've got a question on my problem..
i'm using contrib/fulltextindex to index my tables to do a fulltext search
but i'm using a non-default locale settings on my database.
i found out that if the locale is default 'C' then fulltextindex tables are
scanned very fast using btree indices. for
On Mon, 22 Jul 2002, Christopher Kings-Lynne wrote:
> Would it be worth creating a list of postgres project like this somewhere on
> the postgres site? I had no idea this existed...
It's been listed forever. http://www.us.postgresql.org/interfaces.html
It's about the 17th one from the top.
Vi
It's known problem with LIKE and non-C locale.
You may try contrib/tsearch for full text search. It's works with
locale and does index search.
Oleg
On Mon, 22 Jul 2002, Tomas Lehuta wrote:
> Hello!
>
> i've got a question on my problem..
> i'm using contrib/fulltextindex to index my tabl
Hello!
i've got a question on my problem..
i'm using contrib/fulltextindex to index my tables to do a fulltext search
but i'm using a non-default locale settings on my database.
i found out that if the locale is default 'C' then fulltextindex tables are
scanned very fast using btree indices. for
15 matches
Mail list logo