On Tue, 23 Oct 2001 17:16:06 +0200, you wrote:
CREATE OR DROP VIEW
Is this for real? If I were a database server I would say to the
client please make up your mind :-)
Regards,
René Pijlman [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1:
CREATE OR DROP VIEW
Is this for real? If I were a database server I would say to the
client please make up your mind :-)
I meant DROP IF EXISTS and then CREATE.
This is more simple to implement than CREATE OR REPLACE.
Best regards,
Jean-Michel POURE
---(end of
I find the HISTORY file to be distressingly poor to peruse. Reasons:
A large proportion of the items don't convey any useful information.
Examples:
| PLpgSQL fix for SELECT... FOR UPDATE (Tom)
What did this fix? Does SELECT FOR UDPATE now work whereas it didn't use
to? = SELECT ... FOR
Kovacs Zoltan [EMAIL PROTECTED] writes:
foo=# CREATE TABLE a(foo integer);
CREATE
foo=# CREATE TABLE b(foo integer);
CREATE
foo=# CREATE VIEW c AS SELECT foo FROM a;
CREATE
foo=# CREATE RULE d AS ON INSERT TO c WHERE new.foo=5 DO INSTEAD SELECT foo FROM b;
CREATE
foo=# INSERT INTO c
Robert Dyas [EMAIL PROTECTED] writes:
[ rename and move just about everything in sight ]
Sorry, but I don't think this is going to happen. We'd be breaking
a heck of a lot of user applications, startup scripts, etc to achieve
(IMHO) very little of value. Renaming psql-pgsql would alone break
We used to have to force sequential scans to be disabled because of a very
non-uniform distribution of keys in an index, to actually use the index. We are
a music site and a very large number of keys simply point to a catch-all of
Various Artists or Soundtrack. The 7.2 beta's statistics and
Hello Haller!!!
Your question about - pg_proc
select t.typname from pg_type t , pg_proc p
where p.proname = 'your_stored_procedure' and p.proargtypes[0] = t.oid ;
select t.typname from pg_type t , pg_proc p
where p.proname = 'your_stored_procedure' and p.proargtypes[1] = t.oid ;
...
David Ford [EMAIL PROTECTED] writes:
I traced several calls and they run through a few functions which end
up in pqFlush. These code paths haven't checked the socket to see if it
is ready for RW operation yet. pqFlush calls send() [ignoring SSL].
Where? AFAICS (ignoring the USE_SSL
| Fix for inherited CHECK constraints (Stephan Szabo)
ditto
If this is what I think it is, I think the actual fix was the
following (although I don't know what a particularly good wording
is)
ALTER TABLE ADD CONSTRAINT now properly adds check constraints
to children of the specified
Is there some formal place to make comments on how 7.2b1 works? I'm about
to run it through it's paces on OBSD. Or is this just a 'it's broked'
testing time?
- Brandon
c: 646-456-5455
Lincoln Yeoh wrote:
Also, FWIW, 7.2 includes bytea support for LIKE, NOT LIKE, LIKE ESCAPE,
||, trim(), substring(), position(), length(), indexing, and various
comparators.
Cool!
Would it be practical to use substring for retrieving chunks of binary data
in manageable sizes? Or would
Hello Haller!!
Your question about - pg_proc
select t.typname from pg_type t , pg_proc p
where p.proname = 'your_stored_procedure' and p.proargtypes[0] = t.oid ;
select t.typname from pg_type t , pg_proc p
where p.proname = 'your_stored_procedure' and p.proargtypes[1] = t.oid ;
...
change default account name postgres to pgsql
change daemon name postmaster to pgsqld
change client name psql to pgsql
change data location /var/lib/pgsql/data to /var/pgsql
move .conf files from /var/lib/pgsql/data to /etc/pgsql
*coff*
The more correct (ie. anything but linux) place to
I recently ran pgindent, which had some fixes from the 7.1 version that
were suggested by Tom Lane. Unfortunately, some of my fixes had bad
side effects, and I would like to run pgindent again to correct those
problems Tom has found.
The changes should be minimal, mostly related to indenting of
I cannot use RULEs with WHERE clauses. What's wrong? Is this a bug? I also
had this problem with 7.1.1. The documentation says this should work.
foo=# SELECT version();
version
-
PostgreSQL 7.1.3
I tried posting this a couple times, and I'm not sure why I never saw it, but I
do think it is something worth thinking about.
There was some discussion about pre-forking PostgreSQL, and I gathered that
one of the problems would be how do you know what database to open? At our
shop, we use a
16 matches
Mail list logo
