cvs server: Updating src/backend/utils/mb/conversion_procs/ascii_and_mic
cvs server: failed to create lock directory for
`/projects/cvsroot/pgsql-server/src/backend/utils/mb/conversion_procs/ascii_and_mic'
(/projects/cvsroot/pgsql-server/src/backend/utils/mb/conversion_procs/ascii_and_mic/#cvs.l
Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > ... I think I'll bite the bullet and store the ON COMMIT data in the
> > system catalogues per SQL99. Thoughts?
>
> Seems like the very hard way, considering that there's no reason at all
> for the ON COMMIT status to survive a given
On Wed, 2002-08-14 at 08:32, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > SQL99 is pretty clear about temporary tables, at least.
>
> It is ... and in fact the spec's notion of a temp table has nearly
> nothing to do with ours. They contemplate a temp table as an abstract
> tab
Gavin Sherry <[EMAIL PROTECTED]> writes:
> ... I think I'll bite the bullet and store the ON COMMIT data in the
> system catalogues per SQL99. Thoughts?
Seems like the very hard way, considering that there's no reason at all
for the ON COMMIT status to survive a given backend run. I'd certainly
Change made.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > In fact, I now see that there was no such problem. I do wonder why the
> > 32 is there, though? Shouldn't it be 6 or something like that?
>
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Maybe if some index had the indisclustered bit set one could select
> > that; but is it possible for some table to have more than one index with
> > it? Intuition (but no code observation) says no.
>
> At the moment that bit will n
Gavin Sherry <[EMAIL PROTECTED]> writes:
> ... do we want to modify every 7.2 error message?
Nyet ... but I don't think tacking an offset onto the end of
"parse error at or near foo" messages is likely to cause the
sort of generalized havoc you suggest ...
I'm on record as favoring a thorough re
Gavin Sherry wrote:
> Bruce,
>
> I intend on addressing this by completely rewriting the patch. When I
> spoke to Tom and yourself about merging it with 7.3 at OSCON I argued that
> storing the ON COMMIT data in a global linked list was better (strictly
> for performance reasons). Given that I've
Bruce,
I intend on addressing this by completely rewriting the patch. When I
spoke to Tom and yourself about merging it with 7.3 at OSCON I argued that
storing the ON COMMIT data in a global linked list was better (strictly
for performance reasons). Given that I've incorrectly implemented DELETE
> > I suggest using the official IANA names and replace all the non-identifier
> > characters by underscores and all upper-case letters with lower-case.
> > So it would be iso_8859_1_to_utf_8. That way it's almost as pretty but a
> > lot more predictable.
>
> Sounds reasonable. I'll look into th
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Rod Taylor wrote:
> Appears there is a problem
/contrib is mostly porting tools and loadable modules. We are actually
trying to trim down /contrib too, so I was afraid it wouldn't work.
If you want, post the code to patches and ask if it should be added to
/contrib. I will do it if I can get agreement.
On Wed, 2002-08-14 at 09:49, Curt Sampson wrote:
> On Wed, 14 Aug 2002, Bruce Momjian wrote:
>
> > OK, great summary. Isn't the bottom-line issue the limitation of not
> > being able to create an index that spans tables?
>
> That would be one way to fix one particular problem. I can think of
>
Gavin, was this addressed?
---
Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > As for your question (and, perhaps, SQL99) I don't seen how it makes any
> > sense to specify ON COMMIT outside of a transaction
On Wed, 14 Aug 2002, Bruce Momjian wrote:
>
> I think this belongs on gborg. Would you create a project there?
Bruce,
A number of people at OSCON did consider this to be a nice contrib
feature. Out of curiousity, what makes it more suitable for gborg?
Thanks,
Gavin
--
I don't think anyone will mind, but you can throw a message to 'general'
just to be sure.
---
Gavin Sherry wrote:
> Bruce,
>
> I was working on this on the train this morning. There are a few
> possibilities I'd like to lo
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> What about a switch to set schema search path as well?
I'm leaning to the thought that this is a bad idea, and that pg_dump
should act in a way that's search-path-independent. But I need to
think more.
> You could also just have the tables
Bruce,
I was working on this on the train this morning. There are a few
possibilities I'd like to look at before I submit another patch.
Before I do, there is one important question that I didn't raise when I
submitted the first patch (which was only a proof of concept kind of
patch). Namely: do
Can I have the updated version of this?
---
Christopher Kings-Lynne wrote:
> Ah doh - I thought it was catching it returning a boolean. I'll fix and
> resubmit.
>
> Chris
>
> - Original Message -
> From: "Joe Con
I think this belongs on gborg. Would you create a project there?
---
Hans-Jürgen Schönig wrote:
>
> At my talk at the Oreilly Open Source Convention I have presented a
> simple tool for journaling databases.
> Tom Lane h
On Wed, 2002-08-14 at 05:07, Curt Sampson wrote:
> On Tue, 13 Aug 2002, Lamar Owen wrote:
>
> > > Curt, I think his reply stems from his frustration of chosen content in
> > > many emails that originate from you. We all pretty well understand
> > > postgres has a broken feature. We all understa
Gavin, have you answered these issues brought up about the patch?
---
Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > Attached is a small patch to scan.l for consideration. It hands
> > yyerror() the position
I am going to take all of your patches, make one mega-patch, then send
it to you for review.
---
Ulrich Neumann wrote:
> Hi Michael,
>
> I know all about the story of PostgreSQL for NetWare.
>
> I will tell you the story
Added to TODO:
o Add ALTER TABLE tab SET WITHOUT OIDS
---
Christopher Kings-Lynne wrote:
> > I don't think it would be easy to do this without rewriting the table,
> > as Alvaro suggested. And if you're go
On Wed, 14 Aug 2002, Bruce Momjian wrote:
> OK, great summary. Isn't the bottom-line issue the limitation of not
> being able to create an index that spans tables?
That would be one way to fix one particular problem. I can think of
another way to fix it right off-hand. (Put the parent's part of
Well, I think it shouldn't disappear for a few releases yet...
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Bruce Momjian
> Sent: Wednesday, 14 August 2002 12:43 PM
> To: Christopher Kings-Lynne
> Cc: Hackers; [EMAIL PROTECTED]; [EMAIL PRO
> Right. Instead of talking in circles, let's figure out how to do it.
> If the issue is only sequence numbers, can we force a column to _only_
> get values from the sequence counter, thereby makeing the index span
> unnecessary? Can't we look up stuff in parent/child index to check for
> collis
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
>>I have no personal preference between period and @ or whatever. See if
>>you can get some other votes for @ because most left @ when the ORDER BY
>>idea came up from Marc.
>
>
> FWIW, I still lean to username@database, so I think
OK, the vote is not shifting from '.' to '@'. Is that how we want to
go? I like the pg_user enhancement. Marc, comments? This was your baby.
---
Hannu Krosing wrote:
> On Wed, 2002-08-14 at 06:00, Bruce Momjian wrote:
>
On Wed, 2002-08-14 at 09:38, Christopher Kings-Lynne wrote:
> > 1. The current implementation is broken.
> >
> > 2. We have no proper description of how a "fixed" implementation
> > should work.
>
> Surely 99% of the implementation problems could be solved with an index type
> tha
Christopher Kings-Lynne wrote:
> > 1. The current implementation is broken.
> >
> > 2. We have no proper description of how a "fixed" implementation
> > should work.
>
> Surely 99% of the implementation problems could be solved with an index type
> that can span tables?
Right. I
On Wed, 14 Aug 2002, Christopher Kings-Lynne wrote:
> Surely 99% of the implementation problems could be solved with an
> index type that can span tables?
Maybe.
But my problem is not so much that it's broken, as nobody can
explain exactly what "fixed" would be. I mean, completely fixed,
not ju
Good point. Some said fulltextindex was better for certain queries, but
if no one can come up with such a case, we can remove it.
---
Christopher Kings-Lynne wrote:
> Hi,
>
> I've just done some performance comparisons be
Scott Shattuck <[EMAIL PROTECTED]> writes:
> I'm seeing the following error about once a week or so:
> 2002-08-13 12:37:28 [24313] FATAL 1: LWLockAcquire: can't wait without
> a PROC structure
Oh? I'd love to see what makes this happen. Can you give more context?
> It's usually preceded by t
Curt Sampson wrote:
> On Tue, 13 Aug 2002, Bruce Momjian wrote:
>
> > Yea, you have to question what value the discussion has, really. We
> > have users of inheritance that like it. If we can get a TODO item out
> > of the disucssion, great, but there doesn't seem to be any direction of
> > whe
On Wed, 2002-08-14 at 06:00, Bruce Momjian wrote:
> Sean Chittenden wrote:
> > > Well, they aren't separate fields so you can't ORDER BY domain. The dot
> > > was used so it looks like a schema based on dbname.
IMHO it should look like an user in domain ;)
> > Sorry, I know it's a single field
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > so, added to TODO:
> > * Have views on temporary tables exist in the temporary namespace
> > TODO updated to remove mention of temporary views.
>
> That's *clearly* backwards. Ignoring our little argument, I think there
> is no d
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > so, added to TODO:
> > * Have views on temporary tables exist in the temporary namespace
> > TODO updated to remove mention of temporary views.
>
> That's *clearly* backwards. Ignoring our little argument, I think there
> is no d
> 1. The current implementation is broken.
>
> 2. We have no proper description of how a "fixed" implementation
> should work.
Surely 99% of the implementation problems could be solved with an index type
that can span tables?
Chris
---(end of broadcast
Hi,
I've just done some performance comparisons between contrib/fulltextindex
and contrib/tsearch. Even with every optimisation I can think of for
fulltextindex, tsearch is 300 times faster ;)
Plus it doesn't require a separate table or complicated queries.
I think we should strongly encourage
Scott Shattuck <[EMAIL PROTECTED]> writes:
> I'd also kill for pg_restore --ignore-existing-objects so I could
> run the darn thing against a database that's already got pl/pgsql
> installed in template1 and the dump file wants to install it again etc.
In general, I think it's a mistake for
> Yeah, I was just about to start working on pg_dump's -t switch.
> It absolutely *must* be made schema-aware for 7.3 (-t schema.table
> doesn't work today) and it seems like we might as well try to allow
> wildcard support. Another thought I had was to accept multiple -t
> switches, eg "pg_dump
On Tue, 13 Aug 2002, Bruce Momjian wrote:
> Yea, you have to question what value the discussion has, really. We
> have users of inheritance that like it. If we can get a TODO item out
> of the disucssion, great, but there doesn't seem to be any direction of
> where the discussion is heading.
S
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Tell you what I'd kill for:
> pg_dump -t users_\* db > users.sql
Yeah, I was just about to start working on pg_dump's -t switch.
It absolutely *must* be made schema-aware for 7.3 (-t schema.table
doesn't work today) and it seems like we migh
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have no personal preference between period and @ or whatever. See if
> > you can get some other votes for @ because most left @ when the ORDER BY
> > idea came up from Marc.
>
> FWIW, I still lean to username@database, so I think we're roughly at
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have no personal preference between period and @ or whatever. See if
> you can get some other votes for @ because most left @ when the ORDER BY
> idea came up from Marc.
FWIW, I still lean to username@database, so I think we're roughly at a
tie. It
Bruce Momjian <[EMAIL PROTECTED]> writes:
> so, added to TODO:
> * Have views on temporary tables exist in the temporary namespace
> TODO updated to remove mention of temporary views.
That's *clearly* backwards. Ignoring our little argument, I think there
is no denying that temp views as such
Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > SQL99 is pretty clear about temporary tables, at least.
>
> It is ... and in fact the spec's notion of a temp table has nearly
> nothing to do with ours. They contemplate a temp table as an abstract
> table schema, if you will, that
Ah, that's why it wasn't in my mailbox. Gavin,
http://groups.google.com/groups?hl=en&lr=&ie=ISO-8859-1&q=replace+view+gavin&btnG=Google+Search&meta=group%3Dcomp.databases.postgresql.*
Gavin Sherry <[EMAIL PROTECTED]> writes:
> It passes all regression tests. There's only one really sketch
Gavin Sherry <[EMAIL PROTECTED]> writes:
> SQL99 is pretty clear about temporary tables, at least.
It is ... and in fact the spec's notion of a temp table has nearly
nothing to do with ours. They contemplate a temp table as an abstract
table schema, if you will, that gets instantiated locally wi
"Sander Steffann" <[EMAIL PROTECTED]> writes:
> Now I am thinking about it, referential integrity also behaves funny with
> temp tables. The following is allowed:
>> create temp table a (x int primary key);
>> create table b (y int references a(x));
It is?
regression=# create temp table a (x in
Gavin Sherry <[EMAIL PROTECTED]> writes:
> I submitted a patch for this a few days ago. Did it not hit pgsql-patches?
It did ... I had some gripes about it ... I thought you were working on
the gripes?
regards, tom lane
---(end of broadcast)--
On Tue, 13 Aug 2002, Jeroen T. Vermeulen wrote:
> On Mon, Aug 12, 2002 at 09:38:00PM -0300, Marc G. Fournier wrote:
> >
> > should be fixed ... looks like just an ownership issue on a new directory
>
>
> More like I uploaded that directory just as you were rsync'ing to
> anonymous CVS and a lock
I posted this earlier but it didn't seem to go through. I apologize in
advance if you've gotten this twice. Since I posted earlier this error
happened 2 additional times. It's now a critical issue for our site:
I'm seeing the following error about once a week or so:
2002-08-13 12:37:28 [24313]
This has been fixed in the current sources. You can test it if you
download the snapshot from our ftp site.
---
eutm wrote:
>Some weeks ago i wrote about one problem(called as
> "Bug of PL/pgSQL parser"):
>
> "eutm"
> > The attached patch adds CONVERSION stuff for cyrillic and
> > win874/1250/1251/1256 encodings.
>
> Thanks. I'll take care of this.
Done. Documents and regression tests have been updated also. I think
now we have implemented all encoding conversions for 7.3 release.
--
Tatsuo Ishii
-
On Tue, 2002-08-13 at 19:54, Christopher Kings-Lynne wrote:
> > I'm finding it hard to visualize situations where I'd want the extra
> > baggage of pg_dump for something like this. If I want the schema at
> > all, I'll probably want it separate from the data so that I can hack
> > the schema conv
On Tue, 13 Aug 2002, Bruce Momjian wrote:
> If you move pg_xlog, you have to create a symlink in /data that points
> to the new location. Initdb would do that automatically, but if you
> move it after initdb, you would have to create the symlink yourself.
> With Thomas's current code, you would
> I'm finding it hard to visualize situations where I'd want the extra
> baggage of pg_dump for something like this. If I want the schema at
> all, I'll probably want it separate from the data so that I can hack
> the schema conveniently --- so I'd want to do a "pg_dump -s -t table"
> and then do
Yea, you have to question what value the discussion has, really. We
have users of inheritance that like it. If we can get a TODO item out
of the disucssion, great, but there doesn't seem to be any direction of
where the discussion is heading.
---
OK, here is the patch to implement db_user_namespace. It includes
documentation.
I had to add to initdb to create a file /data/PG_INSTALLER and have the
postmaster read that on startup to determine the installing user.
---
Bruce Momjian wrote:
> It is hard to argue with this logic.
If he were actually making a technical argument I might actually agree
with you myself.
Thus far all he's done is argue from authority, and in tight circles to
boot.
Which means the term is an accurate description of his behavior ...
Sean Chittenden wrote:
> > Well, they aren't separate fields so you can't ORDER BY domain. The dot
> > was used so it looks like a schema based on dbname.
>
> Sorry, I know it's a single field and that there is no split()
> function (that I'm aware of), but that seems like such a small and
> eas
Gavin Sherry wrote:
> On Tue, 13 Aug 2002, Bruce Momjian wrote:
>
> >
> > You want to hear something funny? When I see the standards quoted, I
> > jump to the end to find out what the person says it really means. I
> > find reading those standards painful. I am glad others are reading
> > the
On Tue, 13 Aug 2002, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Marc G. Fournier writes:
> >> Okay, but if we are going to pull libpqxx, what about the other lib's too?
>
> > Certain things apply to libpqxx that don't all apply to the others libs:
> > It is maintained and
On Tue, 13 Aug 2002, Bruce Momjian wrote:
>
> You want to hear something funny? When I see the standards quoted, I
> jump to the end to find out what the person says it really means. I
> find reading those standards painful. I am glad others are reading
> them.
HAH!
I did a degree in the hi
It is hard to argue with this logic.
---
Curt Sampson wrote:
> On Tue, 13 Aug 2002, Lamar Owen wrote:
>
> > > Curt, I think his reply stems from his frustration of chosen content in
> > > many emails that originate from yo
You want to hear something funny? When I see the standards quoted, I
jump to the end to find out what the person says it really means. I
find reading those standards painful. I am glad others are reading
them.
---
Gavin
> Tradeoffs, again ... What about emitting warnings after table drop
> (easy)/creation (not so easy !) ?
The warnings are certainly there now. Dependency code won't let you do
such a thing without specifying CASCADE.
Hopefully CREATE OR REPLACE VIEW will be applied soon, which solves part
two
Hannu Krosing wrote:
> On Wed, 2002-08-14 at 04:23, Emmanuel Charpentier wrote:
>
>>Hannu Krosing wrote:
>>
>>>I'm trying to propose a scenario where
>>>
>>>1. The SELECT clause defining the view is preserved
>>>
>>>2. DROP of undrlying table/column will _not_ drop the view, but just
>>>mark it
On Tue, 13 Aug 2002, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > My feeling is that either the view is temporary, fully, or it isn't. I
> > don't see having it in the public namespace _and_ removing it on session
> > exit as defensible.
>
> I disagree ... (and who said this
> > > Some mentioned using user@dbname, though the idea of sorting made
> > > several recant their votes.
> > >
> > > So, based on the voting, I think dbname.username is an agreed-upon
> > > feature addition for 7.3. I will work on a final patch with
> > > documentation and post it to the patches
On Tue, 13 Aug 2002, Lamar Owen wrote:
> > Curt, I think his reply stems from his frustration of chosen content in
> > many emails that originate from you. We all pretty well understand
> > postgres has a broken feature. We all understand you see zero value in
>
> Knowing Don to some extent, I
On Wed, 2002-08-14 at 04:23, Emmanuel Charpentier wrote:
> Hannu Krosing wrote:
> >
> > I'm trying to propose a scenario where
> >
> > 1. The SELECT clause defining the view is preserved
> >
> > 2. DROP of undrlying table/column will _not_ drop the view, but just
> > mark it dirty
> >
> > 3. U
On Wed, 2002-08-14 at 04:12, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, I realize that, but when I create an index on a temp table, I can
> > create it even though someone else tries to do the same in another
> > session. If these views on temp tables go away on session
Tom,
I submitted a patch for this a few days ago. Did it not hit pgsql-patches?
Gavin
On Tue, 13 Aug 2002, Tom Lane wrote:
> Emmanuel Charpentier <[EMAIL PROTECTED]> writes:
> > What do you think ?
>
> I think Gavin Sherry is already working on this.
>
> regards, tom la
Bruce Momjian <[EMAIL PROTECTED]> writes:
> My feeling is that either the view is temporary, fully, or it isn't. I
> don't see having it in the public namespace _and_ removing it on session
> exit as defensible.
I disagree ... (and who said this was necessarily the public namespace,
anyway? Per
Hannu Krosing wrote:
> On Wed, 2002-08-14 at 04:08, Emmanuel Charpentier wrote:
>
>>Dear all,
>>
>
> ...
>
>
>>Of course, I am aware that view definitions aren't just stored, but that
>> a lot of rewriting is involved before storing the actual execution
>>plan.Modifying a view definitio
Emmanuel Charpentier <[EMAIL PROTECTED]> writes:
> What do you think ?
I think Gavin Sherry is already working on this.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, I realize that, but when I create an index on a temp table, I can
> > create it even though someone else tries to do the same in another
> > session. If these views on temp tables go away on session exit, and
> > can't be reliab
On Wed, 2002-08-14 at 04:08, Emmanuel Charpentier wrote:
> Dear all,
>
...
> Of course, I am aware that view definitions aren't just stored, but that
> a lot of rewriting is involved before storing the actual execution
> plan.Modifying a view definition would entail re-processing of othe
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, I realize that, but when I create an index on a temp table, I can
> create it even though someone else tries to do the same in another
> session. If these views on temp tables go away on session exit, and
> can't be reliably accessed by other users
Dear all,
The current implementation of views uses OIDs, not table/view names. As
a consequence, when you happen to replace (drop then create) an
underlying table or view, you also have to drop and recreate all views
using this table|view (and this recursively, of course ...).
I stumbled on t
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Does every other user see the view name
>
> If he looks in the schema where the view is created, sure --- it's no
> different from any other non-temp table or view.
>
> > ... on his temp table?
>
> Um, are you thinking that a view
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Does every other user see the view name
If he looks in the schema where the view is created, sure --- it's no
different from any other non-temp table or view.
> ... on his temp table?
Um, are you thinking that a view V created to refer to user 1's tem
Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > It seems to be a broken view not security risk in 7.2.1
>
> The implementation of temp tables has changed completely in CVS tip,
> so experiments with 7.2 aren't very relevant. In CVS tip I believe
> you *could* read the contents of
Hannu Krosing <[EMAIL PROTECTED]> writes:
> It seems to be a broken view not security risk in 7.2.1
The implementation of temp tables has changed completely in CVS tip,
so experiments with 7.2 aren't very relevant. In CVS tip I believe
you *could* read the contents of someone else's temp table,
Sean Chittenden wrote:
> > Some mentioned using user@dbname, though the idea of sorting made
> > several recant their votes.
> >
> > So, based on the voting, I think dbname.username is an agreed-upon
> > feature addition for 7.3. I will work on a final patch with
> > documentation and post it to
On Tue, 2002-08-13 at 21:50, Hannu Krosing wrote:
> On Tue, 2002-08-13 at 20:43, Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > I can go either way on this.
> >
> > AFAICS "create temp view" would have some small advantage of keeping the
> > view's name out of possibly-public
Bruce Momjian <[EMAIL PROTECTED]> writes:
> In fact, I now see that there was no such problem. I do wonder why the
> 32 is there, though? Shouldn't it be 6 or something like that?
Whoever it was was too lazy to count accurately ;-)
I guess I'd vote for changing the code to be
sys = mal
> Some mentioned using user@dbname, though the idea of sorting made
> several recant their votes.
>
> So, based on the voting, I think dbname.username is an agreed-upon
> feature addition for 7.3. I will work on a final patch with
> documentation and post it to the patches list for more comment.
In fact, I now see that there was no such problem. I do wonder why the
32 is there, though? Shouldn't it be 6 or something like that?
---
Neil Conway wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have applied th
Good question. Looked like a possible buffer overrun to me. Of course,
I botched it up. I will fix it.
---
Neil Conway wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have applied the attached patch which change
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have applied the attached patch which changes NAMEDATALEN to 64 and
> FUNC_MAX_ARGS/INDEX_MAX_KEYS to 32.
What is the reasoning behind the following change?
Index: src/bin/psql/command.c
===
I have applied the attached patch which changes NAMEDATALEN to 64 and
FUNC_MAX_ARGS/INDEX_MAX_KEYS to 32. Hopefully this will keep people
happy for a few more years.
initdb required.
---
Christopher Kings-Lynne wrote:
> >
Hannu Krosing <[EMAIL PROTECTED]> writes:
> On Wed, 2002-08-14 at 00:38, Tom Lane wrote:
>> For an embedded system I'd think you'd want to strip out the support
>> code for the unwanted types (ie, the utils/adt/ file(s)), not only the
>> catalog entries.
> But if the types themselves were install
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: 13 August 2002 18:24
> To: Peter Eisentraut
> Cc: Marc G. Fournier; PostgreSQL Development
> Subject: Re: [HACKERS] libpqxx
>
>
> JDBC and ODBC are almost separate projects already, and
> perhaps should be cut
On Wed, 2002-08-14 at 00:38, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > On Tue, 2002-08-13 at 22:38, Tom Lane wrote:
> >> It's still "extensible", it's just not so easily "contractible"...
> >>
> >> I'm not sure that this matters, as I've never heard of anyone actually
> >> t
Sounds good to me, but I have proven very unreliable in guessing others
opinions on this issue.
---
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > That does not change my opinion about the -X/PGXLOG switch though ---
> >
Tom Lane writes:
> * postmaster log to stderr --- does this fail if log output
> exceeds 2G?
That would be an issue of the shell, not the postmaster.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you
1 - 100 of 187 matches
Mail list logo
