On Thu, 2006-06-22 at 12:52 -0400, Andrew Dunstan wrote:
> I believe our supported version is still 2.5.4, which is
> what all my linux systems have.
Its not clear to me why some people have such antipathy toward recent
flex releases, but if our only supported flex version is 2.5.4, I think
this s
Tom Lane wrote:
Yeah. This is not really Slony's fault --- we need a general solution
to that in the backend. I think Neil was working on it, but I dunno
how far along he is.
Yeah, I had wanted to get this into 8.1, but I couldn't find time. I
still plan to work on it for 8.2, unless someone
Bruno Wolff III wrote:
I ran accross an article a few weeks ago that suggested that this wasn't
all that great of an idea. Using HTML 4.01 should be just as useful.
Is there a reason why the FAQ can't be in DocBook, like the rest of the
documentation? That would allow multiple output formats t
Two minor gripes about these new functions:
(1) I think pg_total_relation_size() is a bit more concise and clear
than pg_complete_relation_size().
(2) pg_cancel_backend(), pg_reload_conf(), and pg_rotate_logfile() all
return an int indicating success (1) or failure (0). Why shouldn't these
f
Tom Lane wrote:
If we weren't already forcing an initdb for beta2, I'd say it's a bit
late to be complaining ... but we can fix them "for free" right now,
so why not?
Ok, I'll take a look.
While we're on the subject, the units used by pg_size_pretty() are
incorrect, at least according to the
Tom Lane wrote:
[ itch... ] The IEC may think they get to define what's correct, but
I don't think that squares with common usage. The only people who
think MB is measured in decimal are disk-manufacturer marketroids.
Well, just them and the IEEE :)
While common usage has been to use kB to me
Tom Lane wrote:
I agree with both of those criticisms: total is more in line with our
nomenclature than complete, and the other functions should return void
and ereport when they are unhappy. (Saying "I failed" and not having
any mechanism to report why sucks.)
From reading the code, it sugges
On Thu, 2005-15-09 at 21:09 -0300, Marc G. Fournier wrote:
> Tomorrow afternoon, we are planning on packaging up Beta2 .. if anyone is
> sitting on something that should get in before that happens, or has a bug
> they are sitting on, please let us know ...
One change that I would like to get int
On Thu, 2005-15-09 at 22:31 -0400, Tom Lane wrote:
> I thought we'd more or less dropped that idea based on Andreas'
> responses.
I've heard no argument against renaming pg_complete_relation_size() to
pg_total_relation_size() and changing the functions that return an
integer status code to make th
On Thu, 2005-15-09 at 22:06 -0400, Neil Conway wrote:
> One change that I would like to get into beta2 is the proposed
> refactoring of some of the new system info / administration functions.
Ok, this is done: the changes have been committed to CVS HEAD and the
catalog version number ha
On Fri, 2005-16-09 at 08:47 +0100, Dave Page wrote:
> Perhaps you could allow 24 hours before committing potentially
> controversial changes in future?
My apologies for the rush -- I normally would wait longer for a
consensus. In fact, I _was_ waiting for a consensus until I saw that the
wrap for
On Sat, 2005-17-09 at 14:47 +0200, Magnus Hagander wrote:
> Also, the change to pg_cancel_backend breaks backwards compatibility
> with 8.0, which is a whole lot worse than breaking it with 8.1-beta1.
Yeah, I thought about that (and Bruce and I already discussed it offlist
before I committed the c
On Mon, 2005-19-09 at 16:27 +0200, Hans-Jürgen Schönig wrote:
> I was wondering whether it is possible to teach the planner to handle
> DISTINCT in a more efficient way:
[...]
> Isn't it possible to perform the same operation using a
> HashAggregate?
One problem is that DISTINCT ON is defined to
On Mon, 2005-19-09 at 10:57 -0400, Tom Lane wrote:
> Any change like that would require another initdb. If we were going to
> force another initdb, my vote would be to revert these functions to
> where they were in beta1.
What purpose would that serve? About the only thing purpose I can see is
to
On Wed, 2005-28-09 at 18:35 -0300, Marc G. Fournier wrote:
> The problem isn't whether or not they should be changed, the problem is
> that they were changed *during* beta AND *against* the direction that
> discussion on these changes went
I'm not sure what you mean: what is "the direction that
On Fri, 2005-30-09 at 17:47 -0500, Jim C. Nasby wrote:
> What's wrong with adding pg_cancel_backend(...) RETURNS int as an alias
> for the one that returns boolean, and document that it's deprecated and
> will be removed in the future.
You can't overload functions based on their return type alone.
Applications that frequently use LISTEN/NOTIFY can suffer from
performance problems because of the MVCC bloat created by frequent
insertions into pg_listener. A solution to this has been suggested in
the past: rewrite LISTEN/NOTIFY to use shared memory rather than system
catalogs.
The problem is t
On Thu, 2005-06-10 at 01:14 -0400, Tom Lane wrote:
> The idea of blocking during commit until shmem becomes available might
> work. There's some issues here about transaction atomicity, though:
> how do you guarantee that all or none of your notifies get sent?
> (Actually, supposing that the notif
On Thu, 2005-06-10 at 23:56 -0400, Bruce Momjian wrote:
> True, but are people going to recompile PostgreSQL to use this feature?
> Seems they would have to.
They would need to recompile PostgreSQL to use more than the default
number of user-defined LWLocks, which seems perfectly reasonable to me.
On Sat, 2005-08-10 at 00:42 +0530, sandeep satpal wrote:
> ... please guide me
Two suggestions:
(1) Don't start new threads by replying to an existing thread of no
relevance to the new subject
(2) Spend some time phrasing your question in a coherent manner --
you're more likely to get a useful r
Tom Lane said:
> But I think you might be confusing that with the feature-or-bug
> (depending on one's point of view) that duplicate notifications can be
> merged into one event. I'm inclined to preserve that behavior,
> primarily because not doing so would create a tremendous penalty on
> applica
On Mon, 2005-10-10 at 15:57 -0400, Lane Van Ingen wrote:
> That sounds good, and about what I expected. I am not a C programmer, but
> have access to others who are. Where would I need to put the C function
> in order to have PostgreSQL find it? Any special considerations
> other than putting it in
On Wed, 2005-12-10 at 22:46 -0400, Tom Lane wrote:
> No --- we didn't have any per-buffer spinlocks before 8.1.
Right. To summarize the problem as I understand it: we need to force $CC
not to move loads and stores around spinlock acquire/release. This can't
be done by just marking the spinlock var
On Wed, 2005-12-10 at 23:46 -0400, Bruce Momjian wrote:
> Agreed. I have changed them both to stable. I think xslt_process()
> should be stable because it is unlikely you would want a URL's contents
> to change inside a transaction
Why is it "unlikely"?
If a function's return value for a partic
On Fri, 2005-14-10 at 13:08 +0100, Dave Page wrote:
> Note that when we moderate this we now hide away most of the comments
> that may suggest improvements for the docs and only leave the ones that
> are actually helpful in their own right visible.
> If someone wants access to these to review, ple
On Sun, 2005-16-10 at 01:20 -0700, Kevin McArthur wrote:
> Don't forget insert/update returning.
Omar Kilani has a patch for this:
http://archives.postgresql.org/pgsql-patches/2005-07/msg00568.php
I would like to see it get into 8.2
-Neil
---(end of broadcast)
On Mon, 2005-17-10 at 13:32 -0400, Tom Lane wrote:
> I dislike portability approaches that try to enumerate supported cases,
> rather than being general in the first place.
Do we need to have this on every platform we support? The symbols we
want to hide are internal by convention anyway -- using
On Mon, 2005-17-10 at 16:48 -0500, Jim C. Nasby wrote:
> Sorry if I'm just confused here, but don't LWLocks protect data
> structures susceptible to corruption? And if that's the case don't we
> need to be sure that the compiler can't optimize around them?
LWLocks certainly do protect shared data,
On Tue, 2005-25-10 at 17:43 -0400, Tom Lane wrote:
> What I suggest we do about this is change addImplicitRTE() to set
> inFromCl true for implicitly added RTEs, so that the view rule will
> later be dumped as if the query had been written per spec.
Sounds reasonable. I wonder if this should be ba
On Mon, 2005-07-11 at 20:39 +0530, Sreejesh O S wrote:
> How can I access CVS ?
http://www.postgresql.org/developer/sourcecode/
Please try to do at least a little research before posting.
-Neil
---(end of broadcast)---
TIP 5: don't forget to inc
On Mon, 2005-07-11 at 09:19 -0300, Alvaro Herrera wrote:
> I have another gripe regarding pgindent. Why does it change indenting
> of function declarations?
On a related note, most of these changes are completely bogus:
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/pl_exec.
On Thu, 2005-10-11 at 15:22 -0300, Gustavo Tonini wrote:
> how can i make a checkout from CVS server ? What is the address?
http://www.postgresql.org/developer/sourcecode/
-Neil
---(end of broadcast)---
TIP 4: Have you searched our list archives?
There are currently some rather crude knobs for persuading the planner
to favour certain kinds of query plans: the enable_XXX GUC variables.
Several people have asked for a more flexible way to give hints to the
planner. I'm not interested in implementing fully-general planner hints
at the moment,
On Thu, 2005-12-01 at 18:33 +0800, Christopher Kings-Lynne wrote:
> 36.7.3.5. FOR (integer variant)
>
> In the 8.1 docs. "Label" has been spelt "Labal".
Thanks, fixed in HEAD and REL8_1_STABLE.
-Neil
---(end of broadcast)---
TIP 1: if posting/r
On Thu, 2005-12-01 at 16:38 -0500, Bruce Momjian wrote:
> Maybe it should be:
>
> errno = 0; /* Allow unconditional errno check */
I think any solution that involves adding more duplication at each
strtol() callsite is not great ("Don't Repeat Yourself"). I'd still like
to see this ref
On Thu, 2005-12-01 at 21:01 -0500, Gregory Maxwell wrote:
> If we'd really like to avoid people using the knobs to rig queries,
> how about making them only work with explain analyze, useful for
> debugging but not so useful for actual queries.
That seems a pretty arbitrary limitation. I agree th
On Wed, 2005-11-30 at 10:56 -0500, Tom Lane wrote:
> It's been about a month since 8.1.0 was released, and we've found about
> the usual number of bugs for a new release, so it seems like it's time
> for 8.1.1.
I think one fix that should be made in time for 8.1.1 is adding a note
to the "version
On Mon, 2005-12-12 at 11:50 -0500, Bruce Momjian wrote:
> Are you willing to say that we should always prefer pgport over glibc's
> qsort()?
glibc's qsort is actually implemented via merge sort. I'm not sure why
the glibc folks chose to do that, but as a result, it's not surprising
that BSD qsort
On Mon, 2005-12-12 at 16:19 -0500, Tom Lane wrote:
> It seems that gcc is up to some creative reinterpretation of basic C
> semantics again; specifically, you can no longer trust that traditional
> C semantics of integer overflow hold:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175462
>
On Tue, 2005-12-13 at 22:32 +0100, Joachim Wieland wrote:
> there's a topic that comes up from time to time on the lists, the problem
> that pgsql functions get planned only once and thereafter the same query
> plan is used until server shutdown or explicit recreation of the function.
The problem
I'd like to take a look at fixing the fact that procedural languages do
not check the constraints associated with domain types. I think there
are two separate issues:
(1) In PL/PgSQL, we need to check domain constraints whenever we assign
a new value to a variable of a domain type.
(2) When
Christopher Kings-Lynne wrote:
I hope you mean 'redundant with "PRIMARY KEY" in example'...
Why? SERIAL implies NOT NULL (although PRIMARY KEY does as well, of course).
-Neil
---(end of broadcast)---
TIP 4: Have you searched our list archives?
On Sun, 2006-01-08 at 20:04 -0500, Tom Lane wrote:
> On reflection I think that lookup_rowtype_tupdesc is simply misdesigned.
> We can't have it handing back a pointer to a data structure of unspecified
> lifetime. One possibility is to give it an API comparable to the
> syscache lookup functions,
On Mon, 2006-01-09 at 20:23 +0100, Thomas Hallgren wrote:
> Should I consider this as something to add to the PL/Java TODO list?
Probably, yes (if/when I fix the in-tree PLs I was planning to take a
look at all the externally-maintained ones, although you're welcome to
do it instead).
Before doma
On Mon, 2006-01-09 at 12:57 -0500, Tom Lane wrote:
> I have not been able to think of an efficient way to make it work while
> still handing back a simple TupleDesc pointer --- seems like we'd have
> to contort the API somehow so that the "release" function can find the
> reference count. Any thou
On Mon, 2006-01-09 at 14:51 -0500, Tom Lane wrote:
> Nah, I don't think this works. The problem is that after an inval,
> you may have to provide an updated TupleDesc to new callers while
> old callers still have open reference counts to the old TupleDesc.
Good point.
> However, you might be abl
On Tue, 2006-01-10 at 09:47 -0500, Tom Lane wrote:
> I had a further thought about this. What we're really talking about
> here is a reference-counted TupleDesc structure: it's got no necessary
> connection to TypeCacheEntry at all.
Yeah, I came to basically the same conclusion when implementing
While thinking about how to do memory management for the TupleDesc
refcounting changes, it occurred to me that this coding pattern is
dangerous:
local_var = MemoryContextAlloc(TopMemoryContext, ...);
func_call();
/* ... */
/* update global state */
if (global != NULL)
pfree(global);
global = l
On Wed, 2006-01-11 at 02:58 -0500, Tom Lane wrote:
> One comment is that there are worse things than small memory leaks in
> seldom-followed code paths, especially if those paths are only taken in
> error cases.
While I agree the problem isn't a showstopper, I think it is still
worthy of concern:
I've accepted an offer from Fujitsu Australia Software Technologies to
work on PostgreSQL full-time for them for the next twelve months in
Sydney, Australia. I'll be working with Gavin Sherry and two other
full-time developers from FAST. I'm grateful to Fujitsu for giving me
the opportunity to
Christopher Kings-Lynne wrote:
Out of interest, do you have free reign to code whatever you want, or do
you have a specific set of things to do for Fujitsu? Also, will you be
working on the open source server, or Fujitsu proprietary extensions?
I'll be working on a bit of everything; my initial
I ran the postmaster under valgrind, and ran the regression tests ("make
installcheck") against it. Curiously, this resulted in an assertion
failure:
TRAP: FailedAssertion("!(lock->shared > 0)", File:
"/home/neilc/pgsql/src/backend/storage/lmgr/lwlock.c", Line: 443)
The error is pretty reproducib
I'd like to make it possible to perform function calls in PL/PgSQL
without needing to use PERFORM. I think this would be useful because (a)
it is closer to how PL/SQL works (b) PERFORM is (IMHO) a kludge, and
making it unnecessary would make programming in PL/PgSQL more natural.
Attached is a proo
On Thu, 2004-09-16 at 00:06, Neil Conway wrote:
> Attached is a proof of concept patch that implements this.
Woops, the patch is really attached this time.
-Neil
Index: src/pl/plpgsql/src/gram.y
===
RCS file: /home/neilc/priv
On Thu, 2004-09-16 at 08:52, Marc G. Fournier wrote:
> In recognition of his role as lead developer on the internationalization
> front, as well as his invaluble work in both the build and release
> processes, Peter Eisentraut has been invited, and has accepted, to join
> the Core Committee.
Co
On Thu, 2004-09-16 at 01:05, Tom Lane wrote:
> That seems fairly unworkable. For example
>
> SELECT (2,3,4);
>
> is valid SQL.
Good point. The disambiguation algorithm I suggested isn't sufficient,
but I think there ought to be _some_ reasonable algorithm.
>From glancing over the SQL com
On Thu, 2004-09-16 at 01:19, Andrew Dunstan wrote:
> ISTM that this is being done at the wrong level anyway. I'd like to see
> a facility available in our SQL, e.g.
>
> CALL foo();
>
> with the restriction that foo() should be declared to return void.
I think these are two distinct issues. Th
I'm seeing an intermittent assertion failure while running "make check"
with current sources. I can usually reproduce the problem at least once
out of every 3 or 4 runs of "make check" on each of two different
machines (one is an 866 mhz iBook running OSX, the other is a dual Xeon
@ 2.8 ghz run
On Fri, 2004-09-17 at 00:34, Tom Lane wrote:
> I think Andrew has a point: why aren't they the same issue? It would
> certainly be no harder to support
> func( ... );
> as a SQL statement than as something allowed only in plpgsql.
If there's a consensus that it is better to modify the main
On Fri, 2004-09-17 at 13:18, Tom Lane wrote:
> In my mind this is just a clearer statement of what the policy always
> was ;-). The patch review/application load was never supposed to fall
> entirely on Bruce. The list he maintains is just there to ensure that
> nothing slips through the cracks.
On Wed, 2004-09-22 at 00:16, Bruce Momjian wrote:
> So distutils is now required to build python? If that is intended, I
> will just skip building python. I didn't realize we had new
> requirements for python, but that is fine.
Should this be documented in the installation instructions?
-Neil
On Fri, 2004-09-17 at 01:43, Tom Lane wrote:
> PS: this points up once again that the regression tests do not do very
> well at testing concurrent behavior. We need to think about some sort
> of parallel-test harness that would let us write tests that have better
> odds of catching bugs like this.
On Wed, 2004-09-22 at 15:29, James William Pye wrote:
> I think so.
Patch applied with some additional fixes -- the patch as I applied it is
attached. Thanks!
-Neil
Index: doc/src/sgml/installation.sgml
===
RCS file: /home/neilc/pri
There's a bunch of very ugly code in backend/main/main.c that involves
the preprocessor constants "NOFIXADE" and "NOPRINTADE". The code seems
to be related to support for Alpha and/or ultrix4. NOFIXADE is defined
by port/osf.h and port/ultrix4.h, while NOPRINTADE is not defined as far
as I can tell
On Fri, 2004-09-24 at 00:35, Tom Lane wrote:
> I would be inclined to get rid of the separate NOPRINTADE code and make
> NOFIXADE select both flags.
Barring any objections, I intend to apply the attached patch to HEAD
later today.
-Neil
Index: src/backend/main/main.c
On Fri, 2004-09-24 at 12:30, Neil Conway wrote:
> Barring any objections, I intend to apply the attached patch to HEAD
> later today.
Applied to HEAD.
-Neil
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unre
On Fri, 2004-09-24 at 04:12, Josh Berkus wrote:
> My comments are based on having professionally written several hundred
> thousand lines of procedural code for PostgreSQL, SQL Server, and Oracle.
I haven't used stored procedures as implemented elsewhere, so I
appreciate your comments.
> > If we
On Fri, 2004-09-24 at 01:56, Joe Conway wrote:
> As other's have pointed out, this is very common in the MS SQL Server
> world (and I believe Sysbase also supports it).
>From looking at the docs, it appears this isn't supported by Oracle or
DB2 (correct me if I'm wrong). I can see how it would be
On Fri, 2004-09-24 at 05:52, Alvaro Herrera wrote:
> I don't think we can do that in a standard function, at least not
> without a lot of work.
Can you elaborate on why this would be so difficult?
-Neil
---(end of broadcast)---
TIP 8: explain ana
On Fri, 2004-09-24 at 02:40, Tom Lane wrote:
> I concur with Grant Finnemore's objection as well: people expect
> procedures to be able to return resultsets, ie SETOF something,
> not only scalar values.
IMHO most products (and the standard) define stored procedures as not
returning _anything_, wh
[ apologies if this mail is poorly formatted, posted via webmail ]
Gavin Sherry said:
> For the latest few weeks Neil and I have been discussing unit testing as
> a means of testing Postgres more rigorously.
I should note that we've also been looking at some other ideas, including
different appro
Andrew Dunstan wrote:
2. Won't dissolving away "static" cause naming conflicts?
It might, yes. Those can be resolved, I think. I don't see a good reason
why function names can't be unique across the source tree; at the very
least, it means less irritation for anyone using tags.
3. Unit testing f
The memory context created at src/backend/utils/mmgr/portalmem.c:183
shares the name of the memory context created at portalmem.c:279 (they
are both called "PortalHeapMemory"). Is there a reason for this?
-Neil
---(end of broadcast)---
TIP 5: Have
On Tue, 2004-10-12 at 00:43, Tom Lane wrote:
> Most likely (and I for one will for sure resist any attempt to force
> global uniqueness on static names).
You're right that the issue can be avoided easily enough, but what need
is there _not_ to have globally unique function names?
-Neil
---
On Tue, 2004-10-12 at 05:08, Greg Stark wrote:
> But it seems to me that most of the really hard bugs to find involve subtle
> interactions between functions and the state of the database.
>
> You wouldn't be able to find errors in the semantics of xids for example, or
> in the WAL logic that didn
On Tue, 2004-10-12 at 09:40, Tom Lane wrote:
> Copy-and-paste oversight I'd say. Probably the latter ought to be
> "PortalHoldContext" or some such.
Thanks, that's what I suspected. I've applied the attached fix to HEAD.
-Neil
Index: src/backend/utils/mmgr/portalmem.c
==
On Tue, 2004-10-12 at 08:13, Bin Liu wrote:
> Can somebody explain how the 'parsetree' in the parser( ) function get
> populated? What I saw is just a NIL. And it is not touched else where
> in this file.
"parsetree" is a global variable; it is defined in parser.c, but
declared (via extern) in gra
On Sun, 2004-10-10 at 03:36, Chris Browne wrote:
> There are doubtless cases where the optimizer won't use them where it
> would be plausible to do so; that suggests, to me, possibilities for
> enhancing the optimizer.
Speaking of which, if anyone has any examples of queries for which we
ought to
Gaetano Mendola wrote:
Are you going to fix it for the 8.0 and/or back patch it ?
http://archives.postgresql.org/pgsql-committers/2004-10/msg00229.php
http://archives.postgresql.org/pgsql-committers/2004-10/msg00191.php
plus backpatches to older branches (REL7_3_STABLE, REL7_2_STABLE).
Has there be
Recent versions of GCC support some additional warning flags that I
think would be useful to enable for building PostgreSQL:
-Wmissing-declarations ("Warn if a global function is defined without a
previous declaration.")
-Wdeclaration-after-statement (Recent versions of GCC allow declarations
Currently, the assembly for TAS() on x86 does a non-locking test before
using an atomic operation to attempt to acquire the spinlock:
__asm__ __volatile__(
" cmpb$0,%1 \n"
" jne 1f \n"
" lock\n"
On Wed, 2004-09-29 at 21:37, Bruce Momjian wrote:
> The reason MemSet is a win is not that the C code is great but because
> it eliminates a function call.
A reasonable compiler ought to be able to implement memset() as a
compiler intrinsic where it makes sense to do so. MSVC++ can certainly
do th
Profile-guided optimization is a relatively new GCC feature that
improves the quality of generated code by:
- compiling a copy of the source program with some profiling hooks
- running this copy of the program on some representative input data
- recompiling the program using the profiling data pro
On Thu, 2004-09-30 at 19:49, Peter Eisentraut wrote:
> I doubt that the regression tests are anywhere near representative input
> data. They run a proportion of borderline and error cases that is much
> higher than I would expect in normal use.
That's definitely true. At first glance, the regre
On Fri, 2004-09-24 at 19:28, Neil Conway wrote:
> On Fri, 2004-09-24 at 05:52, Alvaro Herrera wrote:
> > I don't think we can do that in a standard function, at least not
> > without a lot of work.
>
> Can you elaborate on why this would be so difficult?
I never go
On Fri, 2004-10-01 at 06:48, Bruce Momjian wrote:
> Yes, that is what I am thinking. I have worked around other bugs in the
> C code before by doing things with the shell script though this problem
> seems hard to clean up with a shell script. I found GNU indent to be
> even harder to fix.
Have
Marc G. Fournier wrote:
Do we have 'make backend thread safe' listed yet? As I recall it, until
that gets done, parallelization of anything was considered to be a
relatively onerous task, no?
ISTM there's no reason we couldn't parallelize query execution using the
same IPC techniques that we us
Gaetano Mendola wrote:
Here http://www.sans.org/top20/#u9
are listed postgres vulnerability it's sad see that almost all
are related to third part components
"Almost all"? By my count, 12 of the 17 vulnerabilities refer to
legitimate problems in PostgreSQL, its RPM distribution, or the ODBC drive
On Mon, 2004-10-18 at 04:13, Tom Lane wrote:
> Do you have any actual evidence for that opinion? ISTM this is
> dependent on a large set of assumptions about the CPU's bus behavior,
> boiling down to the conclusion that an extra conditional branch is
> cheaper than a locked bus cycle.
I think the
On Mon, 2004-10-18 at 03:50, Tom Lane wrote:
> > -Wmissing-declarations ("Warn if a global function is defined without a
> > previous declaration.")
>
> Hm? We have always used that one.
We've always used -Wmissing-prototypes. The documentation states that
-Wmissing-prototypes instructs GCC to:
On Mon, 2004-10-18 at 12:03, Tom Lane wrote:
> > We've always used -Wmissing-prototypes.
>
> We've always used both.
My apologies -- I don't know where I got the opposite impression.
> Hmm, it looks like -Wmissing-prototypes may be a superset of
> -Wmissing-declarations --- it seems to say that
I've got the CREATE TABLE AS restructuring almost finished, but came
across something that I could use some advice on. The current code
stores the "into" relation (and whether or not that relation has OIDs)
in the Query struct. This is ugly[1], but I'm not sure how to fix it.
The main reason Query
On Mon, 2004-10-18 at 11:53, Tom Lane wrote:
> Only once we've begun to spin. The first time through, it's not at all
> clear whether the extra test is worthwhile --- it's certainly a win if
> the lock is always already held, and certainly a loss if the lock is
> always free
Granted, but I think
On Tue, 2004-10-19 at 02:45, Andrew Dunstan wrote:
> *shrug* OK. Then plperl should probably not be regarded as being as
> "trusted" as we would like. Note that old versions of Safe.pm have been
> the subject of security advisories such as this one
> http://www.securityfocus.com/bid/6111/info/
On Wed, 2004-10-20 at 06:18, Rod Taylor wrote:
> http://secunia.com/advisories/12860/
This seems like a rather inconsequential problem, but it should be
fixed. The first two ideas that come to mind: use temporary files in
$PWD rather than /tmp, or create a subdirectory in /tmp to use for the
tempo
On Fri, 2004-10-22 at 07:54, Simon Riggs wrote:
> If I could go further, I'd like to add this as an option on the command if
> possible, rather than a presumption that all such statements should not be
> logged.
Why is that necessary?
-Neil
---(end of broadcast)
Tom Lane wrote:
Possibly we should make ALTER COLUMN strip any implicit coercions that
appear at the top level of the default expression before it adds on the
implicit coercion to the new column datatype.
That seems like a kludge. When processing a column default expression, we:
(1) Accept the defa
On Mon, 2004-10-25 at 00:30, Tom Lane wrote:
> Not without an initdb (to have another column to put it in).
We're already requiring an initdb for beta4; if this is the right way to
fix this (and I'm not insisting that it is), then ISTM we can just push
back beta4 a few days.
> And it
> would prod
On Wed, 2004-10-27 at 03:57, Tom Lane wrote:
> No doubt this is from the PG_TRY that Neil added a couple days ago.
> I think he is going to take it out again in favor of using AllocateFile,
> so ignore the warnings for now (they're obviously bogus anyway).
Sorry, I didn't see those compile warning
On Fri, 2004-10-29 at 07:35, Josh Berkus wrote:
> Is there any reason that we don't have pg_functions, pg_users, pg_groups and
> other system views?pg_tables and pg_views is really useful, but it would
> be good to cover the other items as well.
pg_functions might be useful, but what would p
901 - 1000 of 1135 matches
Mail list logo
