ever done. Read committed transactions seem broken without
this ability.
Robert Treat
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
messag
ase
> inconvenienced in an effort to purely gain that market share. I usually
> associate increased marketing with decreased quality, and I think the
> causality works *both* ways.
>
Aren't most development efforts made simply to gain market share? After
all, I don&
cacy as one of those) and the folks maintaining those lists seem to
be against letting anyone into their fiefdoms.
Robert Treat
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send
On Thu, 05 Dec 2002 21:26:13 -0500, Philip Warner wrote:
> At 12:12 AM 5/12/2002 -0500, Robert Treat wrote:
> I am happy with increasing market share so long a development is not
> distorted or current users inconvenienced. We have seen the latter with
> the misplaced announcements.
these companies
weren't too happy things were running on linux, and not aix or solaris; are
we seeing a pointy haired trend here? Personally I never understood why our
sales guys didn't just tell them "ok we'll port the service to oracle/solaris
for you, but it's
On Saturday 07 December 2002 11:10 pm, Vince Vielhaber wrote:
> On 5 Dec 2002, Robert Treat wrote:
> > On Thu, 2002-12-05 at 03:28, Dave Page wrote:
> > > www is a closed group consisting of a few of us who actually do the
> > > work on the sites.
> >
> >
ote telling you
> not only why I denied it, but which list you were SUPPOSED to join.
>
fiefdoms!!
Robert Treat
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
I do agree that until we get a coordinated and
open web development process the advocacy group is going to have a much
harder go of it.
Robert Treat
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
een 250 and 3500 rows.
These tables turn over at least every 15 minutes, so I have decided on a
10 minute vacuum interval. As with Phillip's, since they are small
tables, more frequent vacuuming seemed excessive.
>
> For larger or more complex tables, the output of VACUUM ANALYZE mu
hink that'd mostly make
> it harder to interpret the config setting rather than offer any real
> ease of administration.
>
Can we not just have vacuum of a database return a total # of pages
modified and relations modified, and then report suggested free space map
settings? Even this li
tion. I'm not sure where the vacuum/analyze
information would go in this scenario though, so a general software
tuning section does seem appropriate. Do you see a 3.8 Tuning the Server
(Hardware) section as well?
Robert Treat
---(end of broadcast)
a non-inheritance system, I
> would vote for forcing a one column table to be dropped. For PG, I think
> you are right.
>
Just out of curiosity, do any of the SQL specs deal with 0 column
tables? I can't recall any dbms supporting a create table comma
which
this case would seem to do) so if it is done lets make sure we add
documentation to point out that we aren't compliant on this issue.
Robert Treat
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an ap
Is this going to be announced to a wider press audience? Has anyone gone
over the "list of things to do when we release" to make sure things like
the websites getting updated or perhaps getting rpm builds coordinated
has been done?
Robert Treat
On Wed, 2002-12-18 at 09:18, Marc G
On Wed, 2002-12-18 at 09:51, Marc G. Fournier wrote:
> On Wed, 18 Dec 2002, Robert Treat wrote:
>
> > Is this going to be announced to a wider press audience? Has anyone gone
> > over the "list of things to do when we release" to make sure things like
> > the w
If it's all, perhaps we should reword as:
... has a new major version number for this release and will require
recompilation of client code.
Robert Treat
On Wed, 2002-12-18 at 14:59, Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> >A dump/restore is *not* required for
On Thu, 2002-12-19 at 12:58, Bruce Momjian wrote:
> OK, what additional things need to be done for 7.3.1? As far as I know,
> we have done everything.
>
Do we want to coordinate with Lamar or Oliver about having packages
ready to coincide with the release announcement?
Rob
n site is stored
in. Anonymous access and an email of who to send patches to would be
enough if people are worried about me trashing things :-)
Robert Treat
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appro
data point. What would be our default as
> shipped?
If there is no downside to allowing both, probably both. If there is a
downside then ipv4, since it much more likely to be the default on OS's
for the next release or two.
Robert Treat
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
; > What about those of us who want to use \e repeatedly? Will that be
> > in the history buffer?
>
> The number of times I've cursed things over the years, I would have
> thought having the edited query in the history would be more useful than
> \e - the latter is only three key presses any how ;-)
>
Or if the query could be appended after the \e, it would only be a quick
"double-up" to get back to the \e.
Robert Treat
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
)
ORDER BY 1,2;
in 7.3
if you run the 7.2 sql from a 7.3 psql client against a 7.2 server it
will work. One solution might be to create files with the 7.2 queries
in them so you could do something like \i relations to get a list of all
relations in the database.
If someone we're ambitious enough, you probably could modify psql to
store which version of the server it is connected and the use some type
of class structure to call the appropriate sql for the given \ command.
Thats the approach we've taken with phppgadmin 3, and while it
complicates things it does have it's benefits.
Robert Treat
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
es in very handy. I'd be
interested in helping out with this, though Christopher would probably
start throwing things at me if I volunteered :-)
Robert Treat
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
asons that this
was not feasible in the past was that we needed functions that could
return multiple rows and columns easily. Now that we have that in 7.3,
it might be worth revisiting.
Robert Treat
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
t; It's not irrelevant. The original question was a complaint about the ads
> and why we have them - this shows the amount of traffic we get for a
> small portion of the site which can give some idea how busy other bits
> of the sites might get.
>
Perhaps this means we need to
You have to do it in functions because some of the \ commands use
multiple queries and logic inside the C code.
Robert Treat
On Mon, 2003-01-13 at 16:42, Greg Copeland wrote:
> Views or C-functions, I think the idea is excellent. It's the concept
> that I really like.
>
> Gr
Have we decided it's really too difficult to remove all references to a
given sysid when the user is dropped? It seems like we're creating
multiple new problems in an effort to workaround one existing problem.
Robert Treat
On Fri, 2003-01-17 at 12:38, Bruce Momjian wrote:
> T
On Fri, 2003-01-17 at 14:32, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > Have we decided it's really too difficult to remove all references to a
> > given sysid when the user is dropped?
>
> Getting at objects in other databases is considerabl
t your competition is using as FUD, you
will gain new users. We'll see what happens in 7.4 if we do have
replication, native windows support, and PITR, because everyone will have
to come up with some new FUD to sling this way.
Robert Treat
---(end of broadcast)---
lanation of problems/solutions of using md5 passwords inside
postgresql. this has tripped up a lot of people upgrading to 7.3
* possibly go into server resource issues and the pitfalls in giving
free form sql access to just anyone. (Think unconstrained join on all
tables in a database)
hth,
Robert
On Wed, 2003-01-22 at 14:23, Marc G. Fournier wrote:
> If anyone has any 'last minute' issues they would like to see in either,
> please speak now or forever hold your peace :)
>
Can someone post a "changelog" for these releases? Also what tags will
be creat
I don't know if this is terribly helpful, but the message was around in
7.2.x, look at src/backend/access/heap/heapam.c around line 1808 (or
1823 in the 7.3.x code)
That said, I've not seen it before, perhaps you can expand upon what
your function is doing?
Robert Treat
On Mon, 2003-0
anch. In the mean time, if some of the unix oriented guys want
to devise a suggested test plan that can be used to determine if we are
going to call the native windows support "production grade" or merely a
vast improvement over the cygwin developers version, well I bet the
windows folks
I see no reason not to do it and
post it to patches or someplace else (gborg?). That way if someone comes
along and complains they can't compile it with a new bison, we can
always say "Kevin Brown made a patch for that, you can get it at XXX".
Robert Treat
acceptable inside the 8.0 rpm's.
Robert Treat
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
(or a link to the thread). While I'll grant you that
the "it's coming" argument is pretty weak after two releases, that fact
that it may have been a better solution could still hold up.
Robert Treat
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
really handy when doing major upgrades). If you really
have a strong desire to change this, you can.
As I see it, this change would (should?) need to be something that could
be changed in the configure script when building postgresql, as well
changeable via a command line option, any other pla
ections, so we ran with 128 max. I think this is a safe number
on most servers these days (running linux as least) though out of the
box I might be more inclined to limit it to 64. If you do hit a file
descriptor problem, *you are hosed*.
Robert Treat
---(end of broadc
ith INSERT output) with the 7.3
pg_dump. Assuming you haven't done anything too wacky, you should be
able to drop your 7.2 database, reload the 7.2 schema, then load up the
7.3 data. As always, test this out before doing it on a production
system.
Robert Treat
to find the data directory when someone else
> set up the system.
>
find / -name postgresql.conf -print
you now know where all of your configuration files are and where the
data for each of those servers is as well.
(Not I'm not against the idea...)
Robert Treat
t.
Stick with it, I think most of us here can see the value in the option,
but there are valid concerns that it be implemented correctly.
Personally I think a postgresql installation is much more like an apache
installation, which generally contains all of the files (data and
config) under /u
On Thu, 2003-02-13 at 19:22, Adam Haberlach wrote:
> On Thu, Feb 13, 2003 at 05:59:17PM -0500, Robert Treat wrote:
> > On Thu, 2003-02-13 at 15:08, mlw wrote:
> > > Stephan Szabo wrote:
> > >
> > > On Thu, 13 Feb 2003, mlw wrote:
> > Personally I think a
the choice.
>
I agree. Given that we don't have solid explanations on telling people
how to tune the different parameters, nor do we have enough mechanisms
for actually giving people the information they need to determine the
changes they need, a complete auto-tune seems premature.
Robert Tr
On Thu, 2003-02-13 at 14:28, Bruce Momjian wrote:
> Robert Treat wrote:
> > On Thu, 2003-02-13 at 14:06, mlw wrote:
> > >
> > > I will be resubmitting my patch for the 7.3.2 tree.
> > >
> >
> > I'm no core developer, but surely this wont be
On Thu, 2003-02-13 at 14:43, Bruce Momjian wrote:
> Robert Treat wrote:
> > On Thu, 2003-02-13 at 12:13, mlw wrote:
> > >
> > > My patch only works on the PostgreSQL server code. No changes have been
> > > made to the initialization scripts.
> &g
On Thu, 2003-02-13 at 14:51, mlw wrote:
>
>
> Robert Treat wrote:
>
>
> On Thu, 2003-02-13 at 12:13, mlw wrote:
>
>
>
> My patch only works on the PostgreSQL server code. No changes have been
>
> made to the initialization scripts.
>
>
>
&
On Thu, 2003-02-13 at 14:06, mlw wrote:
>
> I will be resubmitting my patch for the 7.3.2 tree.
>
I'm no core developer, but surely this wont be included in the 7.3.x
branch. Any change needs to be made against CVS head.
Robert Treat
---(en
her fully
FHS compliant and/or LSB compliant, we've not done enough work on it.
Robert Treat
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
On Saturday 15 February 2003 09:48 am, mlw wrote:
> Robert Treat wrote:
> >Seems like some are saying one of the problems with the current system
> >is it doesn't follow FHS or LSB. If those are valid reasons to change
> >the system, it seems like a change which does
e
best candidates for removal (100% empty). Is this a valid concern, or am
I misreading something?
Robert Treat
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTE
On Thu, 2003-02-27 at 11:00, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > Now that indexes are getting some reporting, my understanding is an
> > index would report fewer pages overall than it's associated table, but
> > those pages would be comple
I
would guess that by the time all of the protocol changes could be
completed, we'd have win32 or pitr, so it will hopefully be moot.
Robert Treat
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
sible 10.0 because we've added
win32... yuk.
That said, I'll take Tom's position on this that we might as well worry
about whether it's going to be 7.4 or 8.0 once we hit feature freeze; by
then the whole discussion could be irrelevant.
Robert Treat
it sounds like it is actually
going away with the fe/be protocol changes. If thats true, it seems to
me this makes the GUC method the most limiting.
Robert Treat
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an
See chapter 6.6.3. "POSIX Regular Expressions" in the Users Guide
Robert Treat
On Thu, 2003-03-13 at 20:27, Partho Bhowmick wrote:
> Is the regular expression used by Postgres POSIX compliant?
>
> Regards,
> Partho
---(end of broadcast)---
many
of the books out there. I've not encountered much fluff yet, though it
does devote a lot of space to various programming interfaces you might
not be interested in; though all are open standard languages, not any
specific companies. Hopefully when I'm done I can post a thorough
review.
Robert Treat
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
in the new order of the postgresql.conf
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
This message on the admin list has directions for recompiling the 7.3.3
SRPM on red hat 7.2
http://archives.postgresql.org/pgsql-admin/2003-05/msg00409.php
Robert Treat
On Thu, 2003-05-29 at 07:26, ow wrote:
> RH7.3 is a supported distribution for at least 6 months. Any plans to add
> Po
If they have a letter to the editor or web forum, it might be worth
posting the change there in case others reading the article want to try
the compile.
Robert Treat
On Sat, 2003-05-31 at 11:56, Peter Eisentraut wrote:
> A German computer magazine (c't 7/2003) tested the Intel C/C++
pg_dump.
yeah. again Chris tends to hack on pg_dump so he might see it
differently than I (and I haven't looked at psql in months).
(He's on holiday for the next few days btw which is why I'm chiming in)
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} P
share somewhat
common names (max_fsm_relations and max_fsm_pages) or else it would really be
easy to overlook some settings.
Robert Treat
On Saturday 07 June 2003 12:33 pm, Bruce Momjian wrote:
> I think people thought if you were doing SHOW ALL, you were looking for
> a specific v
nformation out. I know
many of our users would welcome that change.
Robert Treat
phpPgAdmin Team
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an approp
Can you send in a report for the supported platforms list?
http://developer.postgresql.org/docs/postgres/supported-platforms.html
Robert Treat
On Tue, 2003-06-10 at 13:16, Martin D. Weinberg wrote:
> Hi folks,
>
> We recently built a dual K8D-based Opteron box running Linux in 64-b
up_id=9764&release_id=136623
It's not supported by anyone and I can't even say if it will work for
you, but it has worked for some in the past and might be a good way to
get your feet wet.
Once you get up and running be sure to come back and help us beta test!
:-)
Robert T
Justin,
can you add this to the release notes section on the sourceforge site if it's
not already there?
Robert Treat
On Saturday 14 June 2003 12:02 am, Justin Clift wrote:
> Hi guys,
>
> Although the "Proof of Concept" build works, it does have a few drawbacks:
>
not know it ;-)
>
> We can't slip this puppy any more --- it's time to wrap her up and
> push her out.
>
Well, I suppose that history has shown that waiting on specific features
causes trouble with postgresql development, but I don't see why a
release can't be bas
27;s been a delay of
> a week because of the server problems hasn't there and wasn't the original
> delay only acceptable on the basis that that was that and there wasn't going to
> be another extension?
>
There really isn't for this release. Any talk of dela
t's old school to actually base versioning on
technical criteria instead of buzzwords, but there's no reason we have
to follow the corporate mold. Still, I'd rather not get into that debate
yet since I don't want to let the win32 guys off the hook yet!
win32 for
On Fri, 2003-06-20 at 10:42, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > On Fri, 2003-06-20 at 06:59, Justin Clift wrote:
> >> The only thing that makes me wince is that we have a protocol change at
> >> PostgreSQL 7.4 release instead of 8.0.
&g
; one.
>
right, which is why core/hackers will decide both what gets into each
releases and when it's released. since i'm not outpacing tom or bruce
in my patch submissions i don't expect them to bend to my whims, but as
someone who follows and participates in postgresql development
hink something like this was either posted to the list, put on gborg,
or maybe hidden in contrib somewhere. I'd like a copy if you don't mind,
I currently use reindex regularly on my database but your script sounds
a little more informational.
Robert Treat
--
Bu
rather than other non-prioritized tasks, and it also helps to ensure a
"killer feature" for those who want such things,
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
On Monday 23 June 2003 10:43 am, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > Here's a sure to be wildly unpopular suggestion:
> >
> > Make the deciding factor for the next release support of "foo" (foo can
> > be win32, pitr, rep
On Mon, 2003-06-23 at 21:36, The Hermit Hacker wrote:
> On Mon, 23 Jun 2003, Robert Treat wrote:
>
> > > The target-date-based approach we've taken in the last couple of
> > > releases seems much more productive.
> > >
> >
> > productive on a
Seems like we should also allow for a windows specific distribution of libpq
as well.
Robert Treat
On Tuesday 24 June 2003 10:43 pm, Bruce Momjian wrote:
> Added to TODO:
>
> * Allow creation of a libpq-onl
On Wed, 25 Jun 2003 08:59:41 -0300 (ADT), "Marc G. Fournier" wrote:
> On Wed, 25 Jun 2003, Robert Treat wrote:
>
> > Seems like we should also allow for a windows specific distribution of libpq
> > as well.
>
> I thought that the win32 stuff was being included
Once you folks are done going through the remaining list of patches, can
we get someone to send a rough list of new features in 7.4 sent over to
-advocacy? Please feel free to highlight any items that you think
warrant special notice from a technical standpoint. Thanks in advance,
Robert Treat
erv2 or something and letting
both projects stand side by side?
as the person doing the legwork, do you see one location or the other as
a hindrance to getting the release done?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of b
nny because it's not in the archives and I didn't receive the
> message to my own inbox.
FWIW I have it. Please be aware that archives isn't updating as of now,
so it's quite likely that it go flummoxed before this patch was sent.
Robert Treat
--
Build A Brighter Lamp :: Linux
one I posted...
>
Marc had been playing with the configs for amavis(?) that seemed to have
created a bit of a black hole for some messages. I noticed one I sent
following up Chris K-L's post about a database not starting never made
it to the list. I checked with the direct recipients a
eclared as integer and is not used before this code nor
> as a column name anywhere.
>
> Does anyone have a clue what is going wrong? I use Postgresql 7.3.3 on
> FreeBSD 4.5.
>
try giving it a default of 0 in the declare statement, if that doesn't
work, post the whole code f
g option which logs the
> > name of the database generating the message.
> >
> > Do we need to add this as a TODO?
> It would be VERY nice to do that, and maybe even the table?
>
Should it be a GUC like log_timestamp that can be applied to all log
messages?
Robert Treat
-
able. of course, I doubt you could make this
foolproof (how to log startup errors in this table?) but it could be a
start.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
housands of smaller-sized tuples.
>
Isn't it possible that the reshuffling of tuples before page 1000 could
open up enough space to move the overly large tuple?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
Yes, it is a done deal. I'm in the process of updating the main web site
and the sourceforge site, hopefully I'll be done sometime this morning.
Robert Treat
On Tue, 2003-07-29 at 09:17, Andrew Dunstan wrote:
>
> Is 7.3.4 a done deal now? If so, the front page of the Pg web
x27;gotchas' into a neophyte-developer-FAQ?
>
There nothing stopping you from submitting improved wording for the FAQ
if you think it would be helpful.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)--
Hey Thierry,
I'm forwarding this on to the hackers group to see if we can get an
authoritative answer, as you don't want to rely on my fuzzy memory. :-)
Anyone know the scoop on this?
Robert Treat
-- Forwarded Message --
Subject: Re: [ANNOUNCE] Postgre
ch
better to add to the rserv.README information about the rserv gborg
project and note that, unless there is substantial development it will
most likely be dropped from 7.5, perhaps moved to it's own gborg
project.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware
On Fri, 2003-08-01 at 15:29, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > On Fri, 2003-08-01 at 14:46, The Hermit Hacker wrote:
> >> Is there anyone actually using rserv who would be adverse to my removing
> >> it from the source tar ball?
>
abase and recreate it from schema.
>
> Will that do for you? Unfortunately that is not transaction safe and any
> clients connected at that time needs to disconnect first. Hopefully you can do
> that in the test environment.
>
Truncate isn't transaction safe either, so that
he is all the better I suppose... :-)
>
> > Proper syntax for his feature would seem like:
> > truncate table [cascade|restrict] ?
>
> Agreed.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
CATE cannot be used as table exception_notice_map references
this one via foreign key constraint $1
21809=# select count(*) from exception_notice_map;
count
---
0
(1 row)
21809=#
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
at they do not
> know about them.
>
IMHO the dropdb/createdb/load schema/load data cycle provides for a
better unit test than the truncate data/load data cycle does, so while I
see this functionality as handy for development, I wouldn't use it for
unit testing.
Robert Treat
--
Build A
IIRC the message at the end of install used to echo out the startup
command (pg_ctl or postmaster), but now it gives some nice information
on how to get help. Should the startup message be put back in? Seems
like it is the most likely thing someone who just installed would want
to know.
Robert
Newton did:
"If I have seen farther than others, it is by standing on the shoulders
of giants", Issac Newton
thanks Vadim,
Robert Treat
--
PostgreSQL :: The Enterprise Open Source Database
---(end of broadcast)---
TIP 3: if posting/readi
On Mon, 2003-08-11 at 13:44, elein wrote:
> Yes, I actually have a libwsock32 because my
> system has wine on it. Wine is a windows
> emulator.
>
Wine Is Not an Emulator :-)
Robert Treat
--
PostgreSQL :: The Enterprise Open Source Database
---(end
Strike that, the how to run message comes at the end of initdb, not
install... Maybe we need a message after install telling newbies like
myself to run initdb... :-P
Robert Treat
On Tue, 2003-08-12 at 09:58, Robert Treat wrote:
> IIRC the message at the end of install used to echo out
I guess
we'll assume that if you use the cascade statement you understand these
risks and accept them.
Really my previous email was simply to point out to anyone implementing
the truncate cascade that truncate currently doesn't care if there is
really any data in the dependent tables, jus
thout using "probably").
>
I'll second this notion. Things like what is effected by DROP...CASCADE
and I believe that changing types from OPAQUE to TRIGGER fall into this
category as well. I'm trying to decide on the implicit FROM, iirc we now
have a GUC to turn this on/off,
> from altering PG_PROTOCOL_EARLIEST in your build. See
> src/include/libpq/pqcomm.h.
>
Tom, just curious as to what your resistance is to this feature? ISTM
that making this admin modifiable doesn't hurt anyone and could be
helpful to some people.
Robert Treat
--
Bu
On Thu, 2003-09-04 at 21:14, Bruce Momjian wrote:
> When I do '\h alter' in psql, the content scrolls off my screen.
>
i think you need a bigger screen
> Should we be using the pager for \h output?
>
in 7.3.4 we do, let me check 7.4...seems to work, though I am on beta
301 - 400 of 848 matches
Mail list logo
