> On FreeBSD/Alpha, current CVS:
...
> ../../../../src/include/utils/int8.h:35: warning: `INT64CONST' redefined
> ../../../../src/include/utils/pg_crc.h:85: warning: this is the location of
> the previous definition
afaict this is OK (that is, the compiled code should work) until we get
the defin
On FreeBSD/Alpha, current CVS:
gmake -C common SUBSYS.o
gmake[4]: Entering directory `/home/chriskl/pgsql/src/backend/access/common'
gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../..
/../src/include -c -o heaptuple.o heaptuple.c -MMD
In file included from ../../../../
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Databases have two grantable rights: CREATE allows creating new regular
>> (permanent) schemas within the database, while TEMP allows creation of
>> a temp schema (and thus temp tables).
> Couldn't the temp schema be permanent (an
Tom Lane writes:
[ All the rest looks good to me. ]
> Databases have two grantable rights: CREATE allows creating new regular
> (permanent) schemas within the database, while TEMP allows creation of
> a temp schema (and thus temp tables).
Couldn't the temp schema be permanent (and unremovable),
> Right. The point is that I don't get those (apparently) with -O2 either,
> with my particular compiler. Hmm. Actually, I *do* get those if I make
> sure that some of the other options are set too; my quick test added -O2
> but left out some of the -w switches. OK, never mind...
btw, now that I'
> and two macros:
>
> RECURSE_OVER_CHILDREN(relid);
> AlterTableDoSomething(childrel,...);
> RECURSE_OVER_CHILDREN_END;
>
> (this seems more straightforward than passing the text of the function
> call as a macro parameter).
The above all looks fine. The other stuff I wouldn't really know a
I read a thread about table lock timeout but don't
know whether anything has been done about it.
Here is what I'd like to do:
I don't want my transactions to be on hold for too
long so I'd like to use a syntax I use on INFORMIX already:
SET LOCK MODE TO [WAIT [second] | NOT
WAIT]
I'm using
> > > The first symptom is failures in the char regression test...
> > initdb --no-locale
>
> Ooh. Thanks, that fixes it. Where would I have found this in the docs? I
> was looking in the wrong place (in configure/build) rather than at
> initdb. Should we have something in the release notes? I se
...
> If you're suggesting setting up an actual database table, I'm not
> sure I see the point. Any system parameter is going to have to be
> tied to backend code that knows what to do with the parameter, so
> it's not like you can expect to do anything useful purely by adding
> table entries. T
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The only thing that I had suggested on occasion was that if nontrivial
> work were to be put into SET DATESTYLE, we might want to consider if a
> certain amount of "cleanup" could be done at the same time. For example,
> the particular date styles ha
Thomas Lockhart writes:
> Not sure. Peter would like to change the SET DATESTYLE support if I
> remember correctly. But I've gotten the impression, perhaps wrongly,
> that this extends to changing features in dates and times beyond style
> settings. If it is just the two-dimensional nature of the
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Hmm. In looking at SET, why couldn't we develop this as an extendable
> capability a la pg_proc?
Well, my thoughts were along the line of providing specialized parsing
subroutines tied to specific GUC variables. There already are
parse_hook and assig
Hmm. In looking at SET, why couldn't we develop this as an extendable
capability a la pg_proc? If PostgreSQL knew how to link up the set
keyword with a call to a subroutine, then we could go ahead and call
that routine generically, right? Do the proposals on the table call for
this kind of impleme
...
> regression=# set seed to 1,2;
> server closed the connection unexpectedly
> (crash is due to assert failure)
Now that I look, the assert is one I put in explicitly to catch multiple
arguments! I wasn't sure what the behavior *should* be, though I could
have done worse than simply checking f
Michael Loftis <[EMAIL PROTECTED]> writes:
> IE I'd like to have the information come back as say a notice or maybe
> as extra information for an EXPLAIN for my purposes, but unless there is
> interest, consensus on how it should be done, and a TODO item made of
> it, I won't be making a patch
Thomas Lockhart wrote:
>>>But I do override some parameters in my Makefile.custom:
>>>CFLAGS+= -g -O0 -DUSE_ASSERT_CHECKING
>>>
>>If you use -O0 then you miss most of the interesting warnings.
>>
>
>?? Not in this case. afaik -O0 suppresses most optimizations (and hence
>does not reorder instru
Tom Lane wrote:
>Michael Loftis <[EMAIL PROTECTED]> writes:
>
>>Also I'd also like to know if there is a way to get the planner to burp
>>out all the possible plans it considered before selecting a final plan
>>or do I need to do a little surgery to get that done?
>>
>
>You can define OPTIMIZ
...
> In particular, you don't get "unused variable" and "variable may not
> have been set before being used" warnings at -O0, because the
> control-flow analysis needed to emit those warnings is not done at -O0.
Right. The point is that I don't get those (apparently) with -O2 either,
with my par
Thomas Lockhart wrote:
>>FWIW, I'm still seeing:
>>gram.y:99: warning: `set_name_needs_quotes' declared `static' but never
>>defined
>
>
> Ack. Sloppy patching. Should be fixed now...
>
> - Thomas
Yup, did the trick.
Thanks,
Joe
---(end of broadca
...
> Ah, but we *have* that ability right now; see Peter's recent changes
> to support per-database and per-user GUC settings. The functionality
> available for handling GUC-ified variables is now so far superior to
> plain SET that it's really foolish to consider having any parameters
> that ar
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> However, it seems to me way past time that we did what needs to be done
>> with variable.c --- ie, get rid of it. All these special-cased
>> variables should be folded into GUC.
> Or in some cases into pg_database? We might want some of this to trav
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> But I do override some parameters in my Makefile.custom:
> CFLAGS+= -g -O0 -DUSE_ASSERT_CHECKING
>> If you use -O0 then you miss most of the interesting warnings.
> ?? Not in this case. afaik -O0 suppresses most optimizations
In particular, you don't
Michael Loftis <[EMAIL PROTECTED]> writes:
> Also I'd also like to know if there is a way to get the planner to burp
> out all the possible plans it considered before selecting a final plan
> or do I need to do a little surgery to get that done?
You can define OPTIMIZER_DEBUG but the interface
> > But I do override some parameters in my Makefile.custom:
> > CFLAGS+= -g -O0 -DUSE_ASSERT_CHECKING
> If you use -O0 then you miss most of the interesting warnings.
?? Not in this case. afaik -O0 suppresses most optimizations (and hence
does not reorder instructions, which is why I use it for
Thomas Lockhart writes:
> But I do override some parameters in my Makefile.custom:
>
> CFLAGS+= -g -O0 -DUSE_ASSERT_CHECKING
If you use -O0 then you miss most of the interesting warnings.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
> I agree that we don't want to reinstate that hack on the gram.y side.
> However, it seems to me way past time that we did what needs to be done
> with variable.c --- ie, get rid of it. All these special-cased
> variables should be folded into GUC.
Or in some cases into pg_database? We might wa
> FWIW, I'm still seeing:
> gram.y:99: warning: `set_name_needs_quotes' declared `static' but never
> defined
Ack. Sloppy patching. Should be fixed now...
- Thomas
---(end of broadcast)---
TIP 2: you can get off all lists at once
[EMAIL PROTECTED] (Thomas Lockhart) writes:
> Log message:
> Remove the definition for set_name_needs_quotes() on the assumption that
> it is now obsolete. Need some regression test cases to prove otherwise...
I agree that we don't want to reinstate that hack on the gram.y side.
Howev
Thomas Lockhart wrote:
>
> btw, I've updated gram.y and variable.c to suppress the reported
> warnings (which I *still* don't see here; that is very annoying).
>
FWIW, I'm still seeing:
gram.y:99: warning: `set_name_needs_quotes' declared `static' but never
defined
Joe
-
> I think it was originally needed only for the CRC code, so we put it
> there to begin with. Clearly should be in a more widely used place now.
> Do you have any opinion whether c.h or int8.h is the Right Place?
> I'm still dithering about that.
In looking at the code, istm that the versions sh
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
>
>>but did *not* get the INT64CONST warning that Tom did. I'm using an
>>updated Red Hat 7.2 box.
>
>
> Probably it depends on compiler version? I'm using gcc 2.95.3.
>
could be:
[postgres@jec-linux pgsql]$ gcc -v
Reading specs from
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> I'm still not sure why the INT64CONST conflict does not show up as a
> warning on my machine, but looking at the code I'm not sure why we would
> ever have had two versions in the first place. Anyone want to take
> responsibility for consolidating it i
Joe Conway <[EMAIL PROTECTED]> writes:
> but did *not* get the INT64CONST warning that Tom did. I'm using an
> updated Red Hat 7.2 box.
Probably it depends on compiler version? I'm using gcc 2.95.3.
regards, tom lane
---(end of broadcast)---
> >> With fairly vanilla configure options, I get...
> > Please be specific on the options and platform.
> HPUX 10.20,
> ./configure --with-CXX --with-tcl --enable-cassert
Boy, how plain-vanilla. *My* configure line is all of
./configure --prefix=/home/thomas/local
But I do override some parame
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> More specifically, the *only* compiler warning I see (other than the
> usual yacc/lex symbol warnings) is that a routine in gram.y,
> set_name_needs_quotes(), is defined but not used. Don't know where that
> routine came from, and afaik I didn't accide
Thomas Lockhart wrote:
>>With fairly vanilla configure options, I get...
>
>
> Please be specific on the options and platform. I do *not* see these
> warnings here with my "fairly vanilla configure options" ;)
>
> Can't fix what I can't see, and we should track down what interactions
> are happ
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> With fairly vanilla configure options, I get...
> Please be specific on the options and platform.
HPUX 10.20,
./configure --with-CXX --with-tcl --enable-cassert
regards, tom lane
---(end of broadcast
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> btw, I've updated the regression tests and results for my platform, but
> other platforms (e.g. Solaris) will need their results files updated...
I committed a fix for HPUX's horology file, and did some extrapolation
to produce a Solaris version; some
> With fairly vanilla configure options, I get...
Please be specific on the options and platform. I do *not* see these
warnings here with my "fairly vanilla configure options" ;)
Can't fix what I can't see, and we should track down what interactions
are happening to get these variables exposed..
> > I'm seeing half a dozen gcc warnings as a result of these patches.
> Where are they?
More specifically, the *only* compiler warning I see (other than the
usual yacc/lex symbol warnings) is that a routine in gram.y,
set_name_needs_quotes(), is defined but not used. Don't know where that
routin
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> I'm seeing half a dozen gcc warnings as a result of these patches.
>> Do you want to fix 'em, or shall I?
> Where are they?
With fairly vanilla configure options, I get
make[3]: Entering directory `/home/postgres/pgsql/src/backend/parser'
gcc -O1 -
> I'm seeing half a dozen gcc warnings as a result of these patches.
> Do you want to fix 'em, or shall I?
Where are they? I haven't noticed anything in the files I have changes;
are the warnings elsewhere?
- Thomas
---(end of broadcast)-
I'm seeing half a dozen gcc warnings as a result of these patches.
Do you want to fix 'em, or shall I?
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lo
OK I know it's been beaten nearly to death, but no clear action has come
of it quite yet. We all seem to agree that there is some non-optimal
way in which the planner handles edge cases (cost wise). I don't
believe that there are any fundamental type faults in any of the logic
because we'd h
btw, I've updated the regression tests and results for my platform, but
other platforms (e.g. Solaris) will need their results files updated...
- Thomas
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http:/
This makes the most sense. One could assume a user who doesn't have
access to a particular database shouldn't know what it's for either.
So making the comments global could be problematic in some cases.
I'll enforce this and send in a patch.
--
Rod
- Original Message -
From: "Dave Page"
I've applied patches to implement an int64-based data/time storage
scheme. I've also accumulated some other minor fixes, which result in an
initdb being required (sorry!).
Note that the *default* timestamp type is now TIMESTAMP WITHOUT TIME
ZONE. This is what we discussed previously for the trans
On Sun, 21 Apr 2002, Tom Lane wrote:
> At this point you're essentially arguing that it's faster to recompute
> the list of item sizes than it is to read it off disk. Given that the
> recomputation would require sorting the list of item locations (with
> up to a couple hundred entries --- more t
Curt Sampson <[EMAIL PROTECTED]> writes:
> Yes, this uses a bit more CPU, but I think it's going to be a pretty
> trivial amount. It's a short list, and since you're touching the data
> anyway, it's going to be in the CPU cache. The real cost you'll pay is
> in the time to access the area of memor
On Sun, 21 Apr 2002, Sander Steffann wrote:
> At the moment all our DBs are on one partition.
Not really, no. It's easy to put in a symlink to put a database on
another partition. It's easy for any object, for that matter, so long as
it's not the sort of thing that gets deleted and re-created by
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: 21 April 2002 19:45
> To: Dave Page
> Cc: Rod Taylor; Hackers List
> Subject: Re: [HACKERS] Really annoying comments...
>
>
> Dave Page <[EMAIL PROTECTED]> writes:
> >> I'm more inclined to rip it out ;-).
>
>
Dave Page <[EMAIL PROTECTED]> writes:
>> I'm more inclined to rip it out ;-).
> Eeep! pgAdmin handles comments coming from multiple pg_description tables
> and it works very well (IMHO) in the pgAdmin UI. By all means make them work
> more sensibly in whatever way seems most appropriate - I'll
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: 19 April 2002 19:54
> To: Rod Taylor
> Cc: Hackers List
> Subject: Re: Really annoying comments...
>
>
> "Rod Taylor" <[EMAIL PROTECTED]> writes:
> > COMMENT ON DATABASE db IS 'Comment';
> > Now switch databases
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> Is everyone Ok with the above? Or do we go about making an pg_fkey
> type table for tracking this stuff?
In general there ought to be a pg_constraint table that records all
types of constraints (not only foreign keys). We blew it once already
by making
> > The first symptom is failures in the char regression test...
> initdb --no-locale
Ooh. Thanks, that fixes it. Where would I have found this in the docs? I
was looking in the wrong place (in configure/build) rather than at
initdb. Should we have something in the release notes? I see (now that
Thomas Lockhart writes:
> I'm sure this has been on the list, but I'm not recalling the
> explanation or workaround. My guess is that it is related to collation
> troubles with the new locale-always-enabled feature. I've tended to
> never enable this stuff in the past.
>
> The first symptom is fa
I'm trying to (finally) get my rather extensive patches (mostly
addressing int8 versions of date/time storage) applied but am now having
trouble with the regression tests.
I'm sure this has been on the list, but I'm not recalling the
explanation or workaround. My guess is that it is related to co
Curt Sampson <[EMAIL PROTECTED]> writes:
> If this is the case, would it be possible to number the commands
> per-transaction, rather than globally?
They are.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9
> Having per-transaction command IDs might allow us to reduce the
range of
> the t_cmin and t_cmax fields. Unfortunately, probably by not all
that
> much, since one doesn't want to limit the number of commands within
a
> single transaction to something as silly as 65536.
If you can figure out how
On Sun, Apr 21, 2002 at 03:46:07PM +0900, Curt Sampson wrote:
> On Sat, 20 Apr 2002, Tom Lane wrote:
>
> > Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> > > 2. If not, would patches be accepted to correct the situation?
> >
> > Go for it.
>
> Yes, please! I'd be happy to review and update
On Sat, 20 Apr 2002, Tom Lane wrote:
> >> I believe we do want to distinguish three states: live tuple, dead
> >> tuple, and empty space. Otherwise there will be cases where you're
> >> forced to move data immediately to collapse empty space, when there's
> >> not a good reason to except that yo
61 matches
Mail list logo
