At 00:18 17/08/2002 -0400, Tom Lane wrote:
>Philip Warner <[EMAIL PROTECTED]> writes:
> > Obviously this is not a 7.3 item, but would people support such
> > functionality going into a future version?
>
>Actually, I wouldn't.
This forces application-based caches, which in turn need indexed local
Am Freitag, 16. August 2002 15:51 schrieben Sie:
> Mario Weilguni <[EMAIL PROTECTED]> writes:
> > Here are the problems I've encountered:
> > * pg_restore tries to create a table with ltree and ltree[] datatypes
> > before the type itself is created, so it fails.
>
> Odd; what are the OIDs of the
On Thu, 15 Aug 2002, Peter Eisentraut wrote:
> > integrate or remove new libpqxx
> > integrate or add to gborg Pg:DBD
> >
> > Seems like gborg is the place for these.
>
> I would volunteer to package libpq++ separately.
Okay, the procedure is simple, but where do we want to put this? Do
On Fri, 16 Aug 2002, Zeugswetter Andreas SB SD wrote:
> > Note that the other obvious way to solve this would be to store all of
> > the information inherited from the parent in the parent table, so that
> > you don't have to do anything special to make all of the constraints and
> > whatnot appl
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > A recent change made XLogDir dynamically sized. There was a question of
> > whether this was a good idea since there are lots of other places that
> > use MAXPGPATH.
>
> > I have now found that pg_resetxlog doesn't compile anymore b
Philip Warner <[EMAIL PROTECTED]> writes:
> Obviously this is not a 7.3 item, but would people support such
> functionality going into a future version?
Actually, I wouldn't. I can think of very few situations where
such caching is useful, and I don't believe that the mechanism required
would p
Sample run:
$ psql -U postgres test
psql: FATAL: user "postgres@test" does not exist
$ psql -U postgres@ test
Welcome to psql 7.3devel, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for h
OK, here is the patch with the suggested changes. I am sending the
patch to hackers because there has been so much interest in this.
---
Tom Lane wrote:
> BTW, I just thought of a small improvement to your patch that elimi
This has been discussed before in the context of misunderstanding the
meaning of 'iscachable', but I now have a use for cached function results,
and have seen at least one other posting with a similar need.
The reason I need it is that I have a few functions that do recursive
inheritance look
Bruce Momjian <[EMAIL PROTECTED]> writes:
> A recent change made XLogDir dynamically sized. There was a question of
> whether this was a good idea since there are lots of other places that
> use MAXPGPATH.
> I have now found that pg_resetxlog doesn't compile anymore because
> XLogDir is a char*
From earlier postings it seems like there is no way to check that a temp
table exists; at the time Tom suggested schemas might solve the problem. I
was wondering if:
(a) schema did solve the problem
or
(b) there was any chance of a backend function to get a temp table OID
(or 0 is
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] (Bruce Momjian) wrote
> >
> > I know the trailing @ is ugly, but it prevents surpises when connecting
> > to the database.
> >
>
> if you would make the magic character a variable then perhaps you could
> prevent the ugly... if/when you turn off th
[EMAIL PROTECTED] (Bruce Momjian) wrote
>
> I know the trailing @ is ugly, but it prevents surpises when connecting
> to the database.
>
if you would make the magic character a variable then perhaps you could
prevent the ugly... if/when you turn off the feature, you could set the
PGSQL_STUPI
It is certainly possibly. We have added that type of functionality to
our inhouse CVS system. Below is an example. We include at the bottom
of the checkin mail a link to the webcvs diff page so you can quickly
see what changed for a particular checkin.
--Barry
wfs checkin by barry 02
On Fri, 16 Aug 2002 12:25:37 -0400 (EDT), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>Manfred Koizar wrote:
>> This is the main point of disagreement: Tom Lane wants lighter
>> macros, I want heavier macros. Which direction shall we go?
>
>Could you or Tom explain that in a way that others could u
A recent change made XLogDir dynamically sized. There was a question of
whether this was a good idea since there are lots of other places that
use MAXPGPATH.
I have now found that pg_resetxlog doesn't compile anymore because
XLogDir is a char* now instead of a char[].
Should I fix pg_resetxlog
Rod Taylor wrote:
> Modified files:
> src/backend/utils/adt: ruleutils.c
>
>
> Is this possible?
> Modified files:
>
>http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/utils/adt/ruleutils.c
>
I'd second that request! Great idea.
Joe
---(end
Is it possible for the cvs emails to include a URL to the appropriate
entries in cvs web?
The below is current:
Modified files:
src/backend/utils/adt: ruleutils.c
Is this possible?
Modified files:
http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/utils/adt/ruleutils.c
Joe Conway wrote:
> Tom Lane wrote:
> > Jan Wieck <[EMAIL PROTECTED]> writes:
> >
> >>Since PL/pgSQL is a loadable module still, we might be able to provide
> >>an upgrade after 7.3 is out instead of waiting for 7.4.
> >
> >
> > Maybe, but you'd have to get the core-code end of it in before bet
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
>
>>Since PL/pgSQL is a loadable module still, we might be able to provide
>>an upgrade after 7.3 is out instead of waiting for 7.4.
>
>
> Maybe, but you'd have to get the core-code end of it in before beta.
> AFAIR Joe's patch doesn't yet
On Fri, 2002-08-16 at 20:03, Bruce Momjian wrote:
> Sure. If I can get one more 'yes' I will submit a new patch with the
> change. It does prevent the namespace collision without mucking up
> pg_shadow. We only need to tell people that global users need to supply
> their username to the client a
Tom Lane wrote:
> BTW, I just thought of a small improvement to your patch that eliminates
> some of the ugliness. Suppose that when we recognize an attempt to
> connect as a global user (ie, feature flag is on and last character of
> username is '@'), we strip off the '@' before proceeding. The
Jan Wieck <[EMAIL PROTECTED]> writes:
> Since PL/pgSQL is a loadable module still, we might be able to provide
> an upgrade after 7.3 is out instead of waiting for 7.4.
Maybe, but you'd have to get the core-code end of it in before beta.
AFAIR Joe's patch doesn't yet cover any return style from a
Bruce Momjian wrote:
>
> Jan Wieck wrote:
> > Bruce Momjian wrote:
> > >
> > > Allow PL/PgSQL functions to return sets
> > >
> > > Is anyone working on this? We will get beaten up if we don't have this
> > > for 7.3 and it is available in other languages.
> >
> > That's true. I think I h
BTW, I just thought of a small improvement to your patch that eliminates
some of the ugliness. Suppose that when we recognize an attempt to
connect as a global user (ie, feature flag is on and last character of
username is '@'), we strip off the '@' before proceeding. Then we would
have:
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> My point has nothing to do with resistance to GUC configurables. Someone
> WILL decide that having it as a default is a *Good Thing* because it's
> there and is useful to them
Which someone would this be? There's no chance that such a proposal
woul
On Fri, 16 Aug 2002, Ross J. Reedstrom wrote:
> On Fri, Aug 16, 2002 at 10:21:12AM -0400, Vince Vielhaber wrote:
>
> > RPMs aren't a good enough reason to put it in. All features aren't
> > installed in an RPM, why would this need to? Besides, anything that
> > is runtime configurable can end
Vince Vielhaber wrote:
> > Once again: *no one* has at any time suggested that any form of this
> > patch should affect the default behavior in the slightest.
>
> Not yet they haven't. What happens when it's decided that this
> *feature* is a good thing and should be the default? Maybe not
> n
It is already there, I think:
fix implicit type coercions that are worse
---
Barry Lind wrote:
> Then shouldn't this appear on the "Open 7.3 issues" list that has been
> circulating around? This seems like an ope
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> We could consider establishing a "soft" connection limit that's somewhat
> >> less than max_connections, and allowing non-superusers to log in only
> >> if the soft limit hasn't been exceeded. This does not guara
On Fri, 16 Aug 2002, Tom Lane wrote:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > Vince Vielhaber writes:
> >>> [ 'user@' patch ]
> >>> whim. Then again as long as 7.2.1 is stable enough for me there's
> >>> no reason to upgrade 'cuze I damn sure ain't going back and changing
> >>> all sorts o
OK, sounds reasonable.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I hadn't looked at flags yet. Thomas's concern, and I think a valid
> > one, is that if we move it from contrib into the main tree,
Barry Lind <[EMAIL PROTECTED]> writes:
> Then shouldn't this appear on the "Open 7.3 issues" list that has been
> circulating around?
It does.
regards, tom lane
---(end of broadcast)---
TIP 3: if posting/reading through Us
Joe Conway <[EMAIL PROTECTED]> writes:
> Is /src/include/port/linux.h the correct place to put this or should
> something more specific to Red Hat 7.3 be used (and if so, any ideas
> about how to detect that Red Hat 7.3 is being used)?
Really what we need is a test on the glibc version, which s
Then shouldn't this appear on the "Open 7.3 issues" list that has been
circulating around? This seems like an open issue to me, that needs to
be addressed before 7.3 ships.
--Barry
Tom Lane wrote:
>Barry Lind <[EMAIL PROTECTED]> writes:
>
>
>>You can no long insert large values into a bigi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Specifically, what is ugly about it? Is it that global users have an @
> at the end of their names? How do we prevent namespace collisions
> _without_ doing this? I am all ears.
The folks who are unhappy about this design basically think that the
nam
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I hadn't looked at flags yet. Thomas's concern, and I think a valid
> one, is that if we move it from contrib into the main tree, people may
> accidentally run pg_resetxlog without understanding the issues involved.
There's already an interlock to prev
Manfred Koizar wrote:
> On Fri, 16 Aug 2002 01:05:07 -0400 (EDT), Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
> >
> > P O S T G R E S Q L
> >
> > 7 . 3 O P E NI T E M S
> >
> >improve macros in new tuple header code (Manfred)
>
> ISTM ther
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> We could consider establishing a "soft" connection limit that's somewhat
>> less than max_connections, and allowing non-superusers to log in only
>> if the soft limit hasn't been exceeded. This does not guarantee that
>> superusers ca
On Fri, 16 Aug 2002 01:05:07 -0400 (EDT), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>
> P O S T G R E S Q L
>
> 7 . 3 O P E NI T E M S
>
>improve macros in new tuple header code (Manfred)
ISTM there's no consensus about what "improve" mean
Curt Sampson wrote:
> On Thu, 15 Aug 2002, Bruce Momjian wrote:
>
> > I would like to know how to move this item forward.
>
> Right now (i.e., in 7.2), the only two options we have for moving the
> log file to a different spindle are mounting it on pg_xlog and using a
> symlink. I doubt many peo
Vince Vielhaber wrote:
> On Thu, 15 Aug 2002, Bruce Momjian wrote:
>
> > I have seen some negative reactions to the feature. I am willing to ask
> > for a vote, if that is what people want. If not, I will apply the patch
> > in the next day or two.
>
> So are you calling for a vote or just wil
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
>
>>I'm running Red Hat 7.3 at home. For the fun of it, I put:
>> #define NO_MKTIME_BEFORE_1970
>>But I'm still getting the < 1970 regression test failures. What else do
>>I need to do?
>
>
> I'd assume you need to select different reg
Absolutely, I have been looking into this and I have some thoughts, but right
now all I was trying to do was some rough implementations just to help me
make sure I understand all / most of the issues. I am very new to hacking on
the guts of the backend.
I plan on posting a formal proposal w
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> What does -f do?
>
> > There is concern that using pg_resetxlog by accident could cause
> > problems, so it will prompt the user for confirmation by default. -f
> > (force) disables that confirmation.
>
> pg_resetxlog already has
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Reindex/btree shrinkage - does reindex need work, can btree be shrunk?
>
> I think there is zero probability that anything will be finished on this
> in the next two weeks, considering that (a) no one is working on it,
> and (b) it's
Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > I don't see a major problem with allowing postgres to login if the
> > connection limit is hit (although I'm not sure it's worth the worry,
> > when 'kill a backend executing SELECT ; psql template1 postgres' works
> > as-is).
>
> max_
On Fri, 2002-08-16 at 09:51, Ross J. Reedstrom wrote:
> On Fri, Aug 16, 2002 at 10:21:12AM -0400, Vince Vielhaber wrote:
>
> > RPMs aren't a good enough reason to put it in. All features aren't
> > installed in an RPM, why would this need to? Besides, anything that
> > is runtime configurable
On Fri, Aug 16, 2002 at 10:21:12AM -0400, Vince Vielhaber wrote:
> RPMs aren't a good enough reason to put it in. All features aren't
> installed in an RPM, why would this need to? Besides, anything that
> is runtime configurable can end up getting its default changed on a
> whim. Then again
Lee Kindness <[EMAIL PROTECTED]> writes:
> Vince Vielhaber writes:
>>> [ 'user@' patch ]
>>> whim. Then again as long as 7.2.1 is stable enough for me there's
>>> no reason to upgrade 'cuze I damn sure ain't going back and changing
>>> all sorts of programs and scripts that have global users.
>
Vince Vielhaber writes:
> [ 'user@' patch ]
> whim. Then again as long as 7.2.1 is stable enough for me there's
> no reason to upgrade 'cuze I damn sure ain't going back and changing
> all sorts of programs and scripts that have global users.
Having read bits and pieces of this thread, can t
Greg Copeland <[EMAIL PROTECTED]> writes:
> I guess I should ask. Do the developers foresee immediate usability
> from [Postgres-R] or are we looking at something that's a year+ away?
Darren Johnson would be the man to answer that, but from what he said
at OSCON it sounded like we'd be seeing so
On Fri, 16 Aug 2002, Tom Lane wrote:
> Vince Vielhaber <[EMAIL PROTECTED]> writes:
> > So are you calling for a vote or just willing to ask for one? I vote for
> > putting it in contrib and letting whoever wants it apply it and use it.
>
> The trouble with putting it in contrib is that that make
On Thu, 2002-08-15 at 15:36, Tom Lane wrote:
> Well, I am, but I'm only speaking for myself here:
>
Fair enough.
> I think there is room for several replication solutions for Postgres
> (three or four, maybe).
If the ideal solution count is merely one with a maybe on two then I
tend to concur
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Reindex/btree shrinkage - does reindex need work, can btree be shrunk?
I think there is zero probability that anything will be finished on this
in the next two weeks, considering that (a) no one is working on it,
and (b) it's not a small task. Push it
"Matthew T. O'Connor" wrote:
>
> Hello, I'm playing with creating an auto vacuum daemon, but it is my first
> time inside the pg source code and I'm a bit lost.
>
> I have gotten as far as having a vacuum daemon created on postmaster startup.
> It's just a fork from the postmaster, cribbed mostl
Mario Weilguni <[EMAIL PROTECTED]> writes:
> Here are the problems I've encountered:
> * pg_restore tries to create a table with ltree and ltree[] datatypes before the
>type itself is created, so it fails.
Odd; what are the OIDs of the table and the datatypes?
> * several functions are already
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> So are you calling for a vote or just willing to ask for one? I vote for
> putting it in contrib and letting whoever wants it apply it and use it.
The trouble with putting it in contrib is that that makes it effectively
unavailable to anyone who inst
Neil Conway <[EMAIL PROTECTED]> writes:
> I don't see a major problem with allowing postgres to login if the
> connection limit is hit (although I'm not sure it's worth the worry,
> when 'kill a backend executing SELECT ; psql template1 postgres' works
> as-is).
max_connections is a hard limit; y
On Fri, 16 Aug 2002, Christopher Kings-Lynne wrote:
> Ross - maybe we could work on a little function for tsearch - parse_query()
> or something like that. It could return true or false depending on whether
> it would cause tsearch to error or not...
In principle, the right way is to use the sa
This is known problem with pg_dump.
Don't remember if it's solved in 7.3
Regards,
Oleg
On Fri, 16 Aug 2002, Mario Weilguni wrote:
> Hi,
>
> I'm using the ltree module and located several problems, I think not all problems
>are really ltree related but might be a pg_dump
Hi,
I'm using the ltree module and located several problems, I think not all problems are
really ltree related but might be a pg_dump/pg_restore problem.
Here are the problems I've encountered:
* pg_restore tries to create a table with ltree and ltree[] datatypes before the type
itself is crea
No you can use:
regression=# select 'the'::mquery_txt;
ERROR: Your query contained only stopword(s), ignored
regression=# select 'good'::mquery_txt;
mquery_txt
'good'
(1 row)
I suggest:
1.
regression=# select 'the'::mquery_txt;
NOTICE: Your query contained only
On Thu, 15 Aug 2002, Bruce Momjian wrote:
> I have seen some negative reactions to the feature. I am willing to ask
> for a vote, if that is what people want. If not, I will apply the patch
> in the next day or two.
So are you calling for a vote or just willing to ask for one? I vote for
putt
I think the areas are at least two -
- funding - who funds it and areas that need funding
- PR - what I described in my previous mail
These are pretty separated.
Iavor
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMA
Bruce Momjian wrote:
> I am willing to talk to anyone about this. There is a reason my phone
> number is in my signature (note new phone number; I just moved.)
>
> Also, I am willing to make trips to companies to talk about
> PostgreSQL.
> I can't make 100's of trips a year, but I try to do at
> > It's nonlocal constraints that are the problem, and here foreign keys
> > and UNIQUE constraints are certainly the canonical examples. Both of
> > these would be largely solved with table-spanning indexes I think.
>
> Note that the other obvious way to solve this would be to store all of
>
67 matches
Mail list logo
