can still do it in
> one line should you want to?
What about rules/views/functions and who knows what else (domains?) might be
dependant on the current type definition? It seems like a pretty big can of
worms really.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
... upon further thought, if the above implementation stands up, istm
that its machinations could also be used to implement the reordering
functionality... ie. rewrite the table and fix up any dependencies as
needed.
way to back track on myself eh?
Robert Treat
--
Build A Brighter Lamp :: Linux
tware up to higher standards. I was reading some
blogs the other day that applied this to PHP's adoption rate over Java and
.net, but your comment made me think this really applies to my$ql and
postgresql as well. check out
http://www.sitepoint.com/forums/showpost.php?p=1121502&
On Saturday 24 April 2004 09:21, Shachar Shemesh wrote:
> Robert Treat wrote:
> >Oh well... let's see if we can find a way to support both...
>
> You are welcome to join the other leg of this thread, then. That one is
> not CCed to advocacy, as it is 100% technical.
>
I&
On Saturday 24 April 2004 08:09, Shachar Shemesh wrote:
> Robert Treat wrote:
> > Anyone who has studied software useability will
> >know that uppercase should, in general, be avoided as it hurts
> > readability.
>
> You convinced me! let's change the SQL standar
is being
petty and/or frivolous? Anyone who has studied software useability will
know that uppercase should, in general, be avoided as it hurts readability.
It isn't about "looking pretty", it's about being more usable.
Robert Treat
--
Build A Brighter Lamp :: Linux Apa
On Fri, 2004-04-23 at 14:28, Andrew Dunstan wrote:
> Robert Treat wrote:
> of course you could just create duplicates of all
> >the functions in both upper and lower case, that way whichever way you
> >fold it matches :-)
> >
>
> That strikes me as an instant recip
amed? Shouldn't all functions be
created without any quoting so they fold to whichever way the settings
are set? Hmm... I see your angle Andrew.. they are going to be created
one way or the other so you'd be hard pressed to do it at any time other
than initdb time... of course yo
On Fri, 2004-04-23 at 11:02, Rod Taylor wrote:
> On Thu, 2004-04-22 at 23:05, Robert Treat wrote:
> > On Thursday 22 April 2004 13:55, Barry Lind wrote:
> > > I think the solution lies in improving www.postgresql.org. At the end
> > > of the day it doesn't matt
folder
lower will now simply be folder upper. the only people who will have a
problem are those who quote on one end but not the other, which is bad
practice anyways... so i would say if your serious about it, make the
patch as GUC "case_folding" for upper or lower and get a ta
we havent done this is a while hows about
initpgdata?
dovetails nicely with PGDATA... at least until that gets deprecated ;-)
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)
ev.mysql.com/downloads/ for one implementation), it's just that it's
a radical departure from "the way things have always been done" and I'm not
confident that there would be enough support to make the changes.
Robert Treat
--
Build A Brighter Lamp :: Linu
On Thursday 01 April 2004 12:52, Tony Reina wrote:
> Last link was wrong.
>
> Here's the correct one.
> http://www.dertech.com/pgmex/pgmex.html
>
Updated website code in CVS, should appear after the next update/build cycle.
Robert Treat
--
Build A Brighter Lamp :: Linu
is also the possibility of publishing a version in
> other more marketing oriented venues.
>
Any plans to update the docs as well?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 9: th
#x27; environment variables.
>
I think this is another vote for "store the PGDATA dir value inside a running
postgresql" so you can query the running database to find out what datafiles
it is using.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {
n files you are using inside the db would certainly be a
bonus... and this would have also solved the original complaint of not
knowing where the $PGDATA path was... connect to the database and query for
it...
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---
RC part of the problem with the initial patch/proposal is that it had
implementation issues following a couple of OS guidelines/specs, and
there was an issue with the pid.
One potential bonus I would see to this type of functionality is that on
some servers I have multiple postgresql.confs on a
again recently) but that doesn't
answer the question of "why isn't the pg_hba.conf viewable from inside
the database" ? Seems a valid question since we show postgresql.conf
info database side.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---
Anyone see a benefit of adding command line flags to initdb to force
lower shared memory use without require a recompile?
Robert Treat
On Mon, 2004-04-05 at 08:53, Andrew Dunstan wrote:
> Greg Sabino Mullane said:
> >
> >
> > Having to recompile initdb.c is probably not
NULL"
> from a statistical point of view, but it is perfectly legitimate to
> have nullable attributes mostly anywhere, so the corresponding advices
> is just an "info".
>
Are you planning on making some type of differentiation on advise that
is performance based r
sues :-)
> > con: feature is desired
> >
> > The issues seem to have been thrashed out ad nauseam. Surely we can put
> > *something* in contrib for this? After all, nobody has to use it if they
> > don't want to.
>
> Shouldn't all of these just be on
ependent on the column, however we automagically drop indexes on
columns when dropping columns without even a notice.
Point being that in the original case, I think the index on the oid column
should be dropped automagically, to follow similar behavior with normal
columns.
Robert Treat
Those pages are wiki based, so anyone can add content to them as they
see fit.
Robert Treat
On Tue, 2004-03-23 at 09:54, Shachar Shemesh wrote:
> Hi,
>
> I'm wondering who's doing the "PostgreSQL on Windows" page
> (http://techdocs.postgresql.org/guides/Windo
Try doing a vacuum full on template1 and restart the database. I've had
to do this before after renaming a database via the system catalogs.
Robert Treat
On Tue, 2004-03-16 at 12:05, Dave Cramer wrote:
> Tom,
>
> Thanks, first of all it wasn't my mess, but someone elses.
ssage. But I don't believe we have any data that says it's a problem
> even if you avoid that pitfall.
>
Yep. The other basic thing I recomend is putting syslog/log output on a
different disk than where your data goes. Maybe not proactical for everyone,
but not a big deal for &qu
recreate a
logging facility as feature complete as syslog when we have syslog available.
ranks right up there with recreate cron, another feature many people think an
enterprise database "has to have". Personally I think in place upgrades are
far, far more important than either of thos
pgfoundry.org
> .pgfoundry.postgresql.org
> point to the same place?
>
I hate to be the fly in this ointment, but wouldn't
.projects.postgresql.org be better? especially if you could
then point people to projects.postgresql.org as the main place to start
loo
d like to do all of that after it actually
> works!
>
Just getting caught up on this thread and had similar thoughts as to Richards.
If there are no objections, I'd like to put the first part of this email up
on techdocs as an explination of our current crash recovery system.
Robe
le would prefer us *not* to use a name that
> includes gforge, because of the risk of confusion. That's how we came up
> with "pgfoundry" in the first place.
>
maybe pgsqlfoundry is a better compromise?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
or much of anything ... that will just
> help drive traffic to that squatter at postgres.net.
>
> This also brings up the thought that if we do want to use pgfoundry.org,
> we'd better register pgfoundry.net and pgfoundry.com before someone
> else does.
>
yug... if we go with postgres
o is true for example) ?
Final thought... I'm a DBA and I think the straight number is simpler, though
could be convinced to go with whichever is higher...
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
o the patch queue, but Tom raised some doubts
about it and it was subsequently removed.
Robert Treat
On Mon, 2004-03-08 at 14:41, Josh Berkus wrote:
> Tom,
>
> > Are you sure you're not thinking of stats for functional indexes?
>
> Positive.I even remember seeing
Very Cool! Can we add this to the list of supported platforms? Also
what do folks think of submitting this as a news blurb to slashdot?
This seems like some "good feelings" type news that is right up thier
alley.
Robert Treat
On Thu, 2004-03-04 at 02:46, Hans-Jürgen Schönig wrot
ime check at row insertion,
> > the right way to express that behavior is with an ON INSERT trigger.
>
> That's not an adequate check; it would allow you later to delete the
> plan without deleting the contract.
>
Wouldn't a FK on both tables be the ap
else you could
toss it up on gborg. Incidentally I think there is already a tool that does
this on sourceforge, but it uses tcl and requires a running webserver, so
it's a little overbearing for most peoples needs imho.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} Postgre
ill in favor of this move if the larger community does
not want to move the main project to a gforge based system? or vice
versa?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 7:
uld require you to use a
second database system would it? Besides which we can always use red
hats bugzilla port if need be. I know people have a lot of issues with
it, but if it works for a project of red hats size, i think it would
work for us...
Robert Treat
--
Build A Brighter Lamp :: Linu
On Wed, 2004-02-25 at 03:19, Jonathan M. Gardner wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I'm not sure if my original reply made it through. Ignore the last one if
> it did.
But I liked the last one :-)
>
> On Tuesday 24 February 2004 1:48 pm,
ensure that
> any transactions committed during that period still make it to durable
> storage.
>
Yes, roll back any existing/uncommited transactions and shutdown those
connections, but make sure that committed transactions are stored on disk
before exiting completly.
Robert Treat
--
to
> from techdocs.
Done. :-)
>
> If you could identify candidate keys on a view, you could conceivably automate
> the process even more. That's got to be possible in some cases, but I'm not
> sure how difficult it is to do in all cases.
>
it seems somewhere be
tch to add NO WAIT to the LOCK
> command, so we will see if we can get that into CVS.
>
Is it premature to add "allow vacuum command to use no wait semantics on
locks" to the TODO list?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
nction's return type
ERROR: pg_atoi: error in "one": can't parse "one"
so ISTM that your example is certainly a deficiency if not a bug.
hmm..examples above on 7.3, which didnt support check constraints, so this is
potentially different on 7.4.
Robert Treat
On Thursday 0
gt; this point).
>
> Anyway, this should be supported by all RENAME commands, not just ALTER
> TABLE.
Rod, can you lay out some psdueo code / logic involved in the process? I'm
guessing you lock the entry in pg_class, you up dependent objects, lock them,
update them all... is th
ifferentiate the two different cases. what is needed
i think is a lock_timeout, which times out soley for cases where the lock can
not be aquired in a speedy manner.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)-
get specific about it. We have the
infrastructure on techdocs to publish this, and once started we could use it
to determine what should or should not be added to the standard docs.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
On Tue, 2004-02-10 at 15:40, Rod Taylor wrote:
> On Tue, 2004-02-10 at 15:37, Robert Treat wrote:
> > On Tue, 2004-02-10 at 13:20, Rod Taylor wrote:
> > > > >http://www.microsoft.com/sql/yukon/productinfo/top30features.asp
> > >
> > > > Notice the S
fly. That is a pretty slick trick.
>
I was trying to decide how much better this was than
BEGIN;
DROP INDEX foo ON bar;
CREATE INDEX foo ON bar;
COMMIT;
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)
On Sat, 2004-02-07 at 02:07, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > Don't know if I would agree for sure, but i the second vacuum could see
> > that it is being blocked by the current vacuum, exiting out would be a
> > bonus, since in most
e won't agree with me.
>
Don't know if I would agree for sure, but i the second vacuum could see
that it is being blocked by the current vacuum, exiting out would be a
bonus, since in most scenarios you don't need to run that second vacuum
so it just ends up wasting resources (
o chance of getting in as it is GPL'd code... so step one
would be convincing him to relicense it.
As a side note, I thought Joe Conway also had an implementation of
this...
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end o
o gcc,
which seems to fit into your scenario above. Incedentally they do
distribute a compiled PostgreSQL with their packages, though it's based
on 7.2 according to the author.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
It's not ideal, but can you dump those tables using INSERT commands and load
them into your database?
Robert Treat
On Wednesday 14 January 2004 13:53, [EMAIL PROTECTED] wrote:
> Hi all,
>
> I resend this mail because I didn't have any answer; I still did'nt find
> any
I can't be the only one forsee frustration from users who typo the set
search_path statement and then can't figure out why their tables aren't
showing up... can we emit a warning that not all of the schemas in the
search path were found?
Robert Treat
On Fri, 2004-01-16 a
Chris,
do you have any additional info (email?) on how to contact the original
project admin? Is it possible for you to manually set up Shachar as admin on
the project?
Robert Treat
On Monday 12 January 2004 04:30, Shachar Shemesh wrote:
> Robert Treat wrote:
> >Can you fill us i
on table).
>
> Well, I have about half a patch for column privileges lying around, but
> I've never had enough motivation to do the other, more complicated
> half...
>
Is there a TODO and TODO.detail warrented here?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middlew
e failed and the code is no longer being maintained, we can
contact the gborg maintainer about making you the admin for the project. I
don't think there is an official policy on this, but this seems like a
reasonable request as long as your willing to either update the old code or
leave it as
aking) for me to remember because I'm
> used to psql's way of doing things, since I mostly use it.
>
I'd second this point; I've certainly stumbled over the "show" syntax when
trying to get anything other than tables in mysql.
Robert Treat
--
Build A Brighte
ss for updating these pages? Perhaps they should be moved into the
wiki framework up on techdocs?
Robert Treat
On Wed, 2003-12-17 at 21:37, Bruce Momjian wrote:
> I have put up a list of projects being worked on and their TODO lists in
> hope that people will find it easier to work on
: You might be able to solve this problem by running the REINDEX
command. Of course if you do that you'll destroy all evidence of what
caused the problem, possibly forcing this problem on other users in the
future because you were unwilling to help us to improve the software.
But we underst
commend anyone interested in developing pl's,
whether enhancing old ones or creating new ones, to check out the plR
code on gborg, it was written recently and is pretty advanced.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
On Tue, 2003-12-09 at 12:32, Andrew Dunstan wrote:
> PL/Java would be way cool, though, and have
> very significant appeal, and is very much worth doing, I believe. (Not
> that I have the time to do it.)
>
http://pljava.sourceforge.net/
Someone did it but it didn't catch fir
Yahoo!: yscrappy ICQ: 7615664
>
> ---(end of broadcast)---
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
Built fine on the phppgadmin demo
eign keys.
Theres certainly potential for trouble with this method I suppose but it
seems like it accomplish what the original poster requires...
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
f them, like
phpPgAdmin, are able to function completely across versions.
Robert Treat
On Wed, 2003-11-26 at 08:12, Daniel Kalchev wrote:
> I know this is an attempt to save myself reading the mailing list, but still
> the issue remains:
>
> the psql from version 7.4 does not talk t
uing about these issues on finding a better name,
> I'm sure we can think of one ;-)
>
Seems merging the two would work... attlogpos, the attributes logical
position.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end
override percentage or the default percentages based on
rel_tuples (or rel_pages). This would give autovacuum a place to look
for each table as to when it should vacuum, and gives administrators the
option to tweak it on a per table basis if they find they need a
specific table to vacuum at a differ
function code, so reconnecting will erase that cache.
>
Would it be worth putting in a partial implementation? I'm thinking
specifically about functions that return table types. Could they be
hooked up with dependency information and made to complain?
Robert Treat
--
Build A Bri
led by this
outburst :-)
Robert Treat
On Wed, 2003-11-19 at 17:17, Austin Gonyou wrote:
> All,
>
> I sincerely apologize for possibly starting a flame war, I wasn't aware
> this might be a hot-button issue. Hopefully some good will come of it
> none-the-less, like others who come
On Wed, 2003-11-19 at 10:47, Sailesh Krishnamurthy wrote:
> >>>>> "Mike" == Mike Mascari <[EMAIL PROTECTED]> writes:
>
> Mike> Robert Treat wrote:
>
> >> While some form of bitmapped indexing would be cool, other ideas might
>
On Wed, 2003-11-19 at 12:16, Sailesh Krishnamurthy wrote:
> >>>>> "Robert" == Robert Treat <[EMAIL PROTECTED]> writes:
>
> Robert> allowing indexes for searching nulls, or adding
> Robert> concurrency to GIST, or allowing non btree index
able to implement ARC over LRU, but there are a host
of other strategies that could also be implemented.
I think there are other good projects in there, like allowing indexes
for searching nulls, or adding concurrency to GIST, or allowing non
btree indexes to handle unique's
Robert Treat
--
B
If by up to date you mean 7.4, your probably going to have to wait, but
I believe that Command Prompt, dbExperts, Red Hat, and SRA all have some
type of binary based support available.
Robert Treat
On Tue, 2003-11-18 at 17:19, Austin Gonyou wrote:
> I've been looking all over but I ca
owner that it needs to be
> >checked would do, I would think ...
> >
>
> If there's general interest I'll try to cook something up. (This kind of stuff is
> right up my alley). I'd prefer some automated display of results, though. A simple
> CGI
http://www-inst.eecs.berkeley.edu/~cs186/hwk0/index.html
Are these screenshots of PgAccess on Mac OSX?
Robert Treat
On Tue, 2003-11-18 at 13:07, Sailesh Krishnamurthy wrote:
>
> PostgreSQL most definitely works great on Solaris x86 !
>
> At UC Berkeley, we have our undergraduate s
On Friday 14 November 2003 14:23, Neil Conway wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Robert Treat wrote:
> >> people would always want to have those choices (especially for doing
> >> development/testing/benchmarking between the different methods) the
On Friday 14 November 2003 12:03, Jan Wieck wrote:
> Robert Treat wrote:
> > On Fri, 2003-11-14 at 10:32, Jan Wieck wrote:
> >>
> >> Or did you mean ARC itself? Since it replaced the old LRU code, it is
> >> the only choice you have now. Which sort of raises t
f? Since it replaced the old LRU code, it is
> the only choice you have now. Which sort of raises the question if we
> would want to have multiple choices, like a config option
>
> buffer_replacement_strategy = lru|lru2|arc
>
people would always want to have those choices (especial
always, you can report errors if you want or wait
until they sort it out.
You should still be able to get an RC2 build with the appropriate tags
applied. HTH
Robert Treat
On Wed, 2003-11-12 at 21:04, elein wrote:
>
> What is the status of CVS head? Isn't it in sync
> with 7.
On Wed, 2003-11-12 at 10:23, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > Also (and maybe someone from Red Hat can weigh in here) are there any
> > plans from Red Hat to release RHEL rpms for postgresql in the future,
>
> I can tell you that Red Hat i
r plans to make sure the community rpm builders would have access
to those platforms in order to build rpms against them?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 3: if posting/
On Fri, 2003-11-07 at 18:37, Andrew Dunstan wrote:
> Robert Treat wrote:
> >On Fri, 2003-11-07 at 15:28, Andrew Dunstan wrote:
> >>Marc G. Fournier wrote:
> >>>On Fri, 7 Nov 2003, Robert Treat wrote:
> >>>>I know most people have talked about using bugz
>
Last I check it was the whole thing... techdocs runs on its own VM, the
other sites all run on a different VM. We need to kill the old VM, but
until we move techdocs to it's new home, we can't
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---
On Fri, 2003-11-07 at 15:28, Andrew Dunstan wrote:
> Marc G. Fournier wrote:
>
> >On Fri, 7 Nov 2003, Robert Treat wrote:
> >
> >
> >
> >>I know most people have talked about using bugzilla, but is anyone
> >>familiar with GNATS? I'm current
people have talked about using bugzilla, but is anyone
familiar with GNATS? I'm currently rereading Open Sources and there's a
paragraph or two mentioning it's use and the fact that it can be
interfaced with completely by email.
Robert Treat
--
Build A Brighter Lamp :: Linux A
f we combine www and advocacy (and
> maybe even developer?) into one big site... I would like that Idea, I think I will
> create a little sample page later to see how it could look like :)
>
I disagree... the tech and the content are separate issues, let's keep
them that way or
On Thursday 06 November 2003 17:18, Peter Eisentraut wrote:
> Robert Treat writes:
> >
> > we don't need links, we need patches
> >
>
> Let me ask you the questions that people always ask of us:
>
> How does one get involved?
post proposals to pgsql-www
On Thu, 2003-11-06 at 09:46, Alvaro Herrera wrote:
> On Thu, Nov 06, 2003 at 09:25:38AM -0500, Robert Treat wrote:
>
> > The advocacy site does have different requirements than the main site,
> > namely its bi-lingualness and the different target audience, but perhaps
> >
t was originally created the guy doing the main website
and the guy doing the advocacy website weren't big on nuzzling together.
The advocacy site does have different requirements than the main site,
namely its bi-lingualness and the different target audience, but perhaps
with adding bi
anyone wants to be able to poke around on the
> system, we can arrange that too. Feel free to ask any questions.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
der Irix.
>
> Is it just bison that creates the problem?
>
bison should only be causing troubles if your building from cvs, not
from the beta package...
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
gt; That's all I need --- a consensus that is isn't significant enough to be
> on this list.
>
Does this prevent me from recreating databases that might have improper
data in the foreign key fields? If i would have been able to upgrade
these database in all prior versions but wil
worked fine on slackware:
==
All 93 tests passed.
==
Linux phppgadmin 2.4.18 #2 Fri May 31 01:21:23 PDT 2002 i586 unknown
oh... different kernel, different filesystem
Robert Treat
On Fri, 2003-10-24 at 16:37, Rod Taylor wrote:
> Linux ns2 2.4
6-pc-linux-gnu, compiled by GCC 2.96
(1 row)
qqq74=# \q
[EMAIL PROTECTED] bin]$ uname -a
Linux camel 2.4.20-20.7 #1 Mon Aug 18 15:00:59 EDT 2003 i686 unknown
[EMAIL PROTECTED] bin]$
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
-
efault should be to adopt the current search path (at the time of
> CREATE FUNCTION) as the function's permanent path.
>
Well, you certainly need a way to do both, since IMHO the most useful
would be to have the search path be equal to the callers search path,
On Wed, 2003-10-15 at 16:20, Robert Treat wrote:
> On Wed, 2003-10-15 at 16:00, Marc G. Fournier wrote:
> >
> > Okay, after feeling stupid about the last one (altho I hadn't thought to
> > read the CREATE INDEX page, only the CREATE SCHEMA one), I really hate to
>
27;m right your having a heck of a bad day, but I believe the problem
is you have no ; after each of your sql statements...
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
ng postgresql, and perhaps point them some place for that. What I'd
like to see added to the message is a reminder to run initdb...
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
What's the last beta version that required initdb?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org
will have even better hardware access. Those are the only
> two OS's missing from the Test Drive site.
>
I have a project you could join if you want :-)
http://sourceforge.net/projects/pgsql/
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
lure"?
On the likely chance that 50% fall into 1 and the other into 2, can we
accept a solution than doesn't address both?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
601 - 700 of 848 matches
Mail list logo
