Alvaro Herrera wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Maybe this means that we should give pgindent a run over the back
branches.
Yea, that thought has crossed our minds, but the problem is that there
is little testing of back branches so it would be risky.
That's a fair point,
Greg Sabino Mullane wrote:
I agree that we should do that, but the thread on -hackers (Autovacuum
vs statement_timeout) wasn't totally conclusive. Greg Sabine Mullane
and Peter Eisentraut argued that we shouldn't, but neither provided a
plausible use case where a statement_timeout on restoring a
On Wed, 2008-04-16 at 22:18 -0400, Robert Treat wrote:
* USING query can be a VALUES clause if we wish to do single/few row
operations, so MERGE can be used for bulk-loading and OLTP
* There is no RETURNING option for MERGE, nor for any INSERT/UPDATE
sub-clauses
Is there a reason for
On Thu, Apr 17, 2008 at 09:11:12AM +0300, Heikki Linnakangas wrote:
Something like this:
if (foo)
{
do something;
do something else;
}
...
-
if (foo)
do something;
do something else;
...
I doubt it, indent doesn't know nearly enough C to be able to anything
On Thu, 17 Apr 2008 02:48:37 +0200, Stephen Denne
[EMAIL PROTECTED] wrote:
PFC wrote:
Let's try this quick dirty implementation of a local
count-delta cache
using a local in-memory hashtable (ie. {}).
CREATE OR REPLACE FUNCTION update_count( key TEXT, delta INTEGER )
RETURNS INTEGER
Bruce Momjian wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am reviewing the psql wrap patch and just used pgindent today
to clean it up. (pgindent did not add any extra spacing
changes.) Patch reviewers should probably be able to run
Tom Lane wrote:
Also use this method
for createdb cleanup --- that wasn't a shared-memory-corruption problem,
but SIGTERM abort of createdb could leave orphaned files lying around.
I wonder if we could use this mechanism for cleaning up in case of
failed CLUSTER, REINDEX or the like. I think
Around http://archives.postgresql.org/pgsql-patches/2008-01/msg00089.php it
was proposed to truncate the psql welcome screen. What do you think about
that?
Personally, I'd get rid of it all, because it gets boring after about three
uses, so that we would be at
[EMAIL PROTECTED]:~$ psql
On Mon, 2008-03-31 at 18:21 +, sanjay sharma wrote:
overkill. Compliance requirement for storing private data arises from
each organizations own declared privacy policies and statutory bodies
like privacy commissioners and other privacy watchdogs. These
standards are not as strict as PCI,
Martijn van Oosterhout wrote:
I doubt it, indent doesn't know nearly enough C to be able to anything
other than adjust whitespace. It surely won't remove braces...
I faintly recall that it does or at least did at some point.
--
Sent via pgsql-hackers mailing list
Peter Eisentraut wrote:
Martijn van Oosterhout wrote:
I doubt it, indent doesn't know nearly enough C to be able to anything
other than adjust whitespace. It surely won't remove braces...
I faintly recall that it does or at least did at some point.
It used to remove braces around
Alvaro Herrera wrote:
Tom Lane wrote:
Also use this method
for createdb cleanup --- that wasn't a shared-memory-corruption problem,
but SIGTERM abort of createdb could leave orphaned files lying around.
I wonder if we could use this mechanism for cleaning up in case of
failed CLUSTER,
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Tom Lane wrote:
Also use this method
for createdb cleanup --- that wasn't a shared-memory-corruption problem,
but SIGTERM abort of createdb could leave orphaned files lying around.
I wonder if we could use this mechanism for cleaning up in
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Tom Lane wrote:
Also use this method
for createdb cleanup --- that wasn't a shared-memory-corruption problem,
but SIGTERM abort of createdb could leave orphaned files lying around.
I wonder if we could use this mechanism
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Tom Lane wrote:
Also use this method
for createdb cleanup --- that wasn't a shared-memory-corruption
problem,
but SIGTERM abort of createdb could leave orphaned files lying around.
I wonder if
Heikki Linnakangas wrote:
Sorry if I missed it in the original thread, but what is the use case
you have in mind?
I think the bottom line is just that having statement_timeout a global setting
is stupid for a variety of reasons (dump, restore, vacuum, locks, incidental
delays) that we should
Peter Eisentraut wrote:
Around
http://archives.postgresql.org/pgsql-patches/2008-01/msg00089.php
it was proposed to truncate the psql welcome screen. What do you
think about that?
Personally, I'd get rid of it all, because it gets boring after about
three uses, so that we would be at
If
On Thu, 2008-04-17 at 14:39 +0200, Peter Eisentraut wrote:
Personally, I'd get rid of it all, because it gets boring after about three
uses, so that we would be at
Many people I speak to use Postgres every 6 months or so, so changes
like this make them think its broke when its not.
I'd vote
* Martijn van Oosterhout ([EMAIL PROTECTED]) wrote:
On Wed, Apr 16, 2008 at 05:22:17PM -0400, Tom Lane wrote:
Even if we had some way of letting the application notice that the copy
had already failed, I don't see that psql could do very much with it,
at least not for COPY FROM STDIN. It's
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
Around http://archives.postgresql.org/pgsql-patches/2008-01/msg00089.php it
was proposed to truncate the psql welcome screen. What do you think about
that?
I'd recommend an option in .psqlrc to disable it, if possible. That
would be in line
Peter Eisentraut wrote:
Around http://archives.postgresql.org/pgsql-patches/2008-01/msg00089.php it
was proposed to truncate the psql welcome screen. What do you think about
that?
Personally, I'd get rid of it all, because it gets boring after about three
uses, so that we would be at
Am I missing something..
$ psql -q testdb
testdb=#
And - if you're using bash - you could just
$ alias psql=psql -q
$ psql testdb
testdb=#
On Thursday 17 April 2008 13:39:43 Peter Eisentraut wrote:
Around http://archives.postgresql.org/pgsql-patches/2008-01/msg00089.php
it was proposed
am Thu, dem 17.04.2008, um 14:39:43 +0200 mailte Peter Eisentraut folgendes:
Around http://archives.postgresql.org/pgsql-patches/2008-01/msg00089.php it
was proposed to truncate the psql welcome screen. What do you think about
that?
Personally, I'd get rid of it all, because it gets
Magnus Hagander wrote:
Bruce Momjian wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am reviewing the psql wrap patch and just used pgindent today
to clean it up. (pgindent did not add any extra spacing
changes.) Patch reviewers
Bruce Momjian wrote:
Magnus Hagander wrote:
Bruce Momjian wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am reviewing the psql wrap patch and just used pgindent
today to clean it up. (pgindent did not add any extra
spacing
Mike Aubury wrote:
Am I missing something..
$ psql -q testdb
testdb=#
This also quiets out a few other unrelated things.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
A. Kretschmer wrote:
I'd vote No, because i see very often on #irc people asking something
like 'how can i see the table definition' or other, and in this cases
it's easy to say: hey dude, read the fine welcome message *g*
I take this as evidence that the welcome message has limited use in
Bruce Momjian wrote:
Magnus Hagander wrote:
IIRC, last time I tried it, the failure was because I couldn't get it
to build the proper typedefs. Any chance you could just put a regularly
updated typedefs file somewhere that I could wget down?
Have you tried the CVS version? It should
Magnus Hagander wrote:
Also I can put up a web page where you can upload or email your C
file and get a formatted version back.
IIRC, last time I tried it, the failure was because I couldn't get
it to build the proper typedefs. Any chance you could just put a
regularly updated
Alvaro Herrera wrote:
Bruce Momjian wrote:
Magnus Hagander wrote:
IIRC, last time I tried it, the failure was because I couldn't get it
to build the proper typedefs. Any chance you could just put a regularly
updated typedefs file somewhere that I could wget down?
Have you tried
On Thu, 2008-04-17 at 07:31 +0100, Simon Riggs wrote:
* MERGE will perform a left outer join between source on left and target
on right. There must be no more than 1 row from table-ref for each row
in the table. Each row in the table can only be updated once during each
MERGE
On Thu, 2008-04-17 at 09:30 -0400, Stephen Frost wrote:
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
Around http://archives.postgresql.org/pgsql-patches/2008-01/msg00089.php
it
was proposed to truncate the psql welcome screen. What do you think about
that?
I'd recommend an option
Bruce Momjian wrote:
The source code is the same for both Unix and Windows but you are right
some typedefs are only visible on windows. I think most are from
EXEC_BACKEND so compiling with/without that should help but then you
have to merge the typedef lists, of course.
The source code is
Hello and really thanks for the answer, I found the solution for the problem
also thanks to the gdb debugger. My problem was a SegmentationFault runtime
error due to a little tricky:
the function SPGIST_FUNCTION(pquad_equals_op) is defined as follows
#define SPGIST_FUNCTION(name) extern C Datum
Peter Eisentraut [EMAIL PROTECTED] writes:
Around http://archives.postgresql.org/pgsql-patches/2008-01/msg00089.php it
was proposed to truncate the psql welcome screen. What do you think about
that?
Personally. I'm very seriously against losing the version number banner.
I could do without
I just had an idea about how to create cross-field statistics, which
could greatly improve the quality of estimates involving multiple
conditions on one table. This is rather arm-wavy, but I wanted to at
least get the idea out...
If we built a table via
CREATE TABLE moo AS SELECT i, i*2
Alvaro Herrera [EMAIL PROTECTED] writes:
What are we going to do about the duality of Windows vs. non-Windows?
Perhaps we could collect typedefs generated on the buildfarm.
I think it's really not acceptable that pgindent misformats Windows-only
code (or any other part of the code that Bruce
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 18, 2008 at 12:36 AM, Tom Lane wrote:
Peter Eisentraut writes:
Around it
was proposed to truncate the psql welcome screen. What do you think about
that?
Personally. I'm very seriously against losing the version number
Brendan Jurd wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 18, 2008 at 12:36 AM, Tom Lane wrote:
Peter Eisentraut writes:
Around it
was proposed to truncate the psql welcome screen. What do you think about
that?
Personally. I'm very seriously against losing
On Thu, Apr 17, 2008 at 04:03:18PM +0300, Heikki Linnakangas wrote:
They do clean up on abort or SIGTERM. If you experience a sudden power
loss, or kill -9 while CLUSTER or REINDEX is running, they will leave
behind dangling files, but that's a different problem. It's not limited
to utility
Martijn van Oosterhout [EMAIL PROTECTED] writes:
Is this so? This happened to me the other day (hence the question about
having COPY note failure earlier) because the disk filled up. I was
confused because du showed nothing. Eventually I did an lsof and found
the postgres backend had a large
Peter Eisentraut [EMAIL PROTECTED] writes:
Heikki Linnakangas wrote:
Sorry if I missed it in the original thread, but what is the use case
you have in mind?
I think the bottom line is just that having statement_timeout a global
setting
is stupid for a variety of reasons (dump, restore,
Joe Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
I thought about this in the shower just now, and ISTM that if we want to
turn this into an actual feature rather than a kluge, there needs to be
some sort of define variable command that sets up a custom variable
and specifies its type (and
On Thu, 17 Apr 2008 11:11:58 -0400
Andrew Dunstan [EMAIL PROTECTED] wrote:
Brendan Jurd wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 18, 2008 at 12:36 AM, Tom Lane wrote:
Peter Eisentraut writes:
Around it
was proposed to truncate the psql
Hi all,
since long time I have implemented a materialized view, today I had to add a
new field and I faced the following (I believe) bug.
The bug can be replicated on a 8.2.7
-- SETUP
create table test (a integer, b integer);
create table test_trigger (a integer);
CREATE OR REPLACE FUNCTION
Gaetano Mendola [EMAIL PROTECTED] writes:
since long time I have implemented a materialized view, today I had to add a
new field and I faced the following (I believe) bug.
The bug can be replicated on a 8.2.7
Cached plan for the function's UPDATE. Should work okay in 8.3 ...
Hi hackers,
It occurred to me that psql's \z command could benefit from the
addition of some newlines. With any more than one grantee per object,
the output of \z rapidly becomes extremely wide, and very hard to
read.
I'd like to split the output onto one line per grantee. So, instead of this:
For debugging the planner work I'm about to do, I'm expecting it will be
useful to be able to get EXPLAIN to print the targetlist of each plan
node, not just the quals (conditions) as it's historically done. My
first instinct is just to stick in the code under a debugging #ifdef,
but I wonder if
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
We could just do:
psql 8.1.10 - postgresql server version 8.1.10
Type: \h for SQL help, \? for psql help, \q to quit
Best idea yet. I also still like the .psqlrc no-splash
option, no reason we can't do both.
- --
Greg Sabino Mullane
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Sorry if I missed it in the original thread, but what is the
use case you have in mind?
A use case would be dumping a large table and wanting to
load it into the database, but wanting to stop the job if it
is still running an hour from now,
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
What are we going to do about the duality of Windows vs. non-Windows?
Perhaps we could collect typedefs generated on the buildfarm.
I think it's really not acceptable that pgindent misformats Windows-only
code (or any other part of
Decibel! [EMAIL PROTECTED] writes:
For each field that isn't already in a set of field groupings
* Sort sample rows on that field
* Calculate correlation for all other fields
* If there are other fields that have a correlation to this sort order over
some threshold, save them along with
Bruce Momjian wrote:
Based on that reaction I am not going to bother uploading my copy of the
typedefs.
Please reconsider. Not having pgindent work at all is not better than
it working only 98%.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL
Tom Lane [EMAIL PROTECTED] writes:
For debugging the planner work I'm about to do, I'm expecting it will be
useful to be able to get EXPLAIN to print the targetlist of each plan
node, not just the quals (conditions) as it's historically done. My
first instinct is just to stick in the code
Alvaro Herrera wrote:
Bruce Momjian wrote:
Based on that reaction I am not going to bother uploading my copy of the
typedefs.
Please reconsider. Not having pgindent work at all is not better than
it working only 98%.
That's what I thought, but Tom thinks my list is unacceptable. What
Alvaro Herrera wrote:
Bruce Momjian wrote:
Based on that reaction I am not going to bother uploading my copy of the
typedefs.
Please reconsider. Not having pgindent work at all is not better than
it working only 98%.
I have been thinking of pursuing your suggestion of having
Alvaro Herrera [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Based on that reaction I am not going to bother uploading my copy of the
typedefs.
Please reconsider. Not having pgindent work at all is not better than
it working only 98%.
I think I'm rescinding my objection to checking a
Gregory Stark [EMAIL PROTECTED] writes:
EXPLAIN VERBOSE is indeed ridiculous.
There are other ways to get that printout, too, if you really do need
it.
IMHO You could also move width to VERBOSE while you're at it. In fact you'll
probably want width in precisely the same cases where you want
Andrew Dunstan wrote:
I have been thinking of pursuing your suggestion of having it as a
buildfarm option. We could provide a SOAP interface to collect the
typedefs and then consolidate them and put them in CVS. We could even do
it per release. That would include Windows, although only
Gregory Stark wrote:
The only thing is that if the whole point is to have patch submitters run
pgindent on their own added code it won't work since their own code will be
precisely the code with the missing typedefs. How easy is it to manually add a
handful of typedefs to the list?
The list
Andrew Dunstan [EMAIL PROTECTED] writes:
I have been thinking of pursuing your suggestion of having it as a
buildfarm option. We could provide a SOAP interface to collect the
typedefs and then consolidate them and put them in CVS. We could even do
it per release. That would include Windows,
Tom Lane [EMAIL PROTECTED] writes:
I'm not convinced. The width is often useful to understand why the
planner did something (eg, chose a hash plan or not). The exact
contents of the targetlist are usually not nearly as interesting.
I've never seen a single post on any of the lists where
Gregory Stark [EMAIL PROTECTED] writes:
Or is it estimating the width based on the belief that only the thousand
column is actually going to be emitted?
Right. The width is used to estimate how much space would be needed
for, eg, sorting or hashing the plan node's output. In any case where
[EMAIL PROTECTED] (Simon Riggs) writes:
Should there be a new rule option? ie. ON MERGE rules ?
Maybe, but not as part of this project.
That seems to warrant a bit of elaboration...
If we're running a MERGE, and it performs an INSERT or UPDATE of a
particular tuple in(to) a particular
[EMAIL PROTECTED] (Tom Lane) writes:
Chris Browne [EMAIL PROTECTED] writes:
Would it be a terrible idea to...
- Draw the indent code from NetBSD into src/tools/pgindent
I am not real eager to become maintainers of our own indent fork, which
is what you propose. (Just for starters, what
On Thu, 2008-04-17 at 12:34 -0400, Tom Lane wrote:
I'm tempted to propose redefining the currently-nearly-useless
EXPLAIN VERBOSE option as doing this.
Yes please.
Sounds like a good home for other useful things also.
I'd like to have an EXPLAIN mode that displayed the plan without *any*
Simon Riggs wrote:
On Thu, 2008-04-17 at 09:30 -0400, Stephen Frost wrote:
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
Around http://archives.postgresql.org/pgsql-patches/2008-01/msg00089.php it
was proposed to truncate the psql welcome screen. What do you think about
that?
I'd recommend
I am confused how a hex type is any better than using the 'hex' decode()
format we already support:
test= select decode('5476', 'hex');
decode
Tv
(1 row)
---
Dawid
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
ISTM that we must fix the bgwriter so that ForgetDatabaseFsyncRequests
causes PendingUnlinkEntrys for the doomed DB to be thrown away too.
Because of the asynchronous nature of ForgetDatabaseFsyncRequests, this
Greg Sabino Mullane wrote:
A use case would be dumping a large table and wanting to
load it into the database, but wanting to stop the job if it
is still running an hour from now, when a maintenance window
is scheduled to start.
statement_timeout is pretty useless for that purpose, because it
PFC wrote
[EMAIL PROTECTED] wrote:
I don't know plpythonu (nor python), just read a few docs now:
Learn Python, it is a really useful language ;)
My wife has a snake phobia, besides, I've just started learning Scala.
There is no sharing between processes, so
- both SD
On Thu, 17 Apr 2008 15:58:10 +0200 Peter Eisentraut wrote:
Mike Aubury wrote:
Am I missing something..
$ psql -q testdb
testdb=#
This also quiets out a few other unrelated things.
Like all \timing messages *grumble*
--
Andreas 'ads' Scherbaum
German
On Thu, 17 Apr 2008 09:30:04 -0400 Stephen Frost wrote:
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
Around http://archives.postgresql.org/pgsql-patches/2008-01/msg00089.php
it
was proposed to truncate the psql welcome screen. What do you think about
that?
I'd recommend an option
The big gotcha is that these are all non-transactional
: if you rollback,
GD and SD stay the same, and when you issue a query, you can
assume the
state of SD and GD is random (due to previous queries) unless you
initialize them to a known value.
Using txid_current() as a
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
The closest thing I can think of to an automated test is to run repeated
sets of the parallel regression tests, and each time SIGTERM a randomly
chosen backend at a randomly chosen time. Then see if anything funny
[EMAIL PROTECTED] (Stephen Frost) writes:
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
Around http://archives.postgresql.org/pgsql-patches/2008-01/msg00089.php
it
was proposed to truncate the psql welcome screen. What do you think about
that?
I'd recommend an option in .psqlrc to
On Thu, 17 Apr 2008, Tom Lane wrote:
For debugging the planner work I'm about to do, I'm expecting it will be
useful to be able to get EXPLAIN to print the targetlist of each plan
node, not just the quals (conditions) as it's historically done.
I've heard that some of the academic users of
My wife has a snake phobia, besides, I've just started learning Scala.
Just had a look at Scala, it looks nice. Slightly Lispish (like all good
languages)...
txid_current()
No... hold on, it is per session, and a session can't have two or more
transactions active at once can it?
On Thu, 17 Apr 2008 20:42:49 +0200, Simon Riggs [EMAIL PROTECTED]
wrote:
On Thu, 2008-04-17 at 12:34 -0400, Tom Lane wrote:
I'm tempted to propose redefining the currently-nearly-useless
EXPLAIN VERBOSE option as doing this.
Yes please.
Sounds like a good home for other useful things
Tom Lane [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] writes:
I have been thinking of pursuing your suggestion of having it as a
buildfarm option. We could provide a SOAP interface to collect the
typedefs and then consolidate them and put them in CVS. We could even do
it
I don't think we should define types based on how they print. We should define
types based on what they contain. bytea is a perfectly good datatype for
storing binary data, though perhaps we could use a bytea(n) for fixed size
binary data.
However bytea has an inconvenient string representation.
Heikki Linnakangas [EMAIL PROTECTED] writes:
Patch attached that does the three changes we've talked about:'
- make ForgetDatabaseFsyncRequests forget unlink requests as well
- make rmtree() not fail on ENOENT
- force checkpoint on in dropdb on all platforms
This looks fine as far as it goes,
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
That would certainly be better than the current approach, since
presumably it would cover not only Windows but the other
conditionally-compiled stuff that Bruce chooses not to compile on
his own machine.
It would, as
Gregory Stark [EMAIL PROTECTED] writes:
However bytea has an inconvenient string representation. Really I would prefer
if bytea were *always* read and written in hex format.
Yeah, the escaping rule is a mess: hard to work with and even less
storage-efficient than hex would be.
We could have a
* Tom Lane [EMAIL PROTECTED] [080417 20:11]:
3) How would this work with typedefs which come from system or library
includes?
Ouch, that's a real good point. Maybe a certain amount of platform
dependence is inevitable.
I don't get it. If they are used as typedefs *anywhere* in the
On Apr 17, 2008, at 12:22 PM, Gregory Stark wrote:
Decibel! [EMAIL PROTECTED] writes:
For each field that isn't already in a set of field groupings
* Sort sample rows on that field
* Calculate correlation for all other fields
* If there are other fields that have a correlation to this sort
Aidan Van Dyk [EMAIL PROTECTED] writes:
* Tom Lane [EMAIL PROTECTED] [080417 20:11]:
Ouch, that's a real good point. Maybe a certain amount of platform
dependence is inevitable.
I don't get it. If they are used as typedefs *anywhere* in the PG
source, they're needed in the typedef list.
* Tom Lane [EMAIL PROTECTED] [080417 20:47]:
Right, but if the only use is inside #ifdef __BRAND_X_PLATFORM__,
the only way for the proposed toolchain to extract that usage is
if someone runs it on BRAND_X_PLATFORM.
Of course, for seldom-used platforms maybe we don't care that much.
But
[resending because the first went to -committers which is kind of bogus]
Tom Lane [EMAIL PROTECTED] writes:
Log Message:
---
Fix a couple of oversights associated with the physical tlist optimization:
we had several code paths where a physical tlist could be used for the input
to a
PFC wrote:
Plan = Tree
Tree = XML
If you want to propose a DTD I'm sure there would be many people
interested.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers mailing list
Tom Lane [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
1) I take it we feel safe guaranteeing that we won't use any fancy macros
inside typedefs. So no '#define pgtype(x) _pg_##x' or anythin like
Gregory Stark wrote:
But if we're still doing object file analysis on the build farm and it's easy
to add typedefs manually then perhaps there's not much effort saved by having
such a tool. I think it would be possible to write but it wouldn't really be
easy. You have to parse just enough C to
On Fri, 18 Apr 2008, Gregory Stark wrote:
The reason I was asking these questions was because I was thinking about
how hard it would be to generate the list from a textual analysis
instead of using object files.
Is there some reason I don't understand why the listing doyxgen creates
isn't
Greg Smith wrote:
On Fri, 18 Apr 2008, Gregory Stark wrote:
The reason I was asking these questions was because I was thinking
about how hard it would be to generate the list from a textual analysis
instead of using object files.
Is there some reason I don't understand why the listing
Alvaro Herrera [EMAIL PROTECTED] writes:
Greg Smith wrote:
Scraping that HTML seems like it would be pretty straightforward.
It's awfully incomplete. Bruce said to me the other day on IM that the
list he was getting with the Linux version of find_typedef was something
like 2800 symbols. I
On Thursday 17 April 2008 12:04, Joshua D. Drake wrote:
On Thu, 17 Apr 2008 11:11:58 -0400
Andrew Dunstan [EMAIL PROTECTED] wrote:
Brendan Jurd wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 18, 2008 at 12:36 AM, Tom Lane wrote:
Peter Eisentraut writes:
On Fri, 18 Apr 2008 00:21:58 -0400
Robert Treat [EMAIL PROTECTED] wrote:
We could just do:
psql 8.1.10 - postgresql server version 8.1.10
Type: \h for SQL help, \? for psql help, \q to quit
postgres=#
I think it's getting overlooked because most people don't deal with
it, but I
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Greg Smith wrote:
Scraping that HTML seems like it would be pretty straightforward.
It's awfully incomplete. Bruce said to me the other day on IM that the
list he was getting with the Linux version of find_typedef was something
Robert Treat [EMAIL PROTECTED] writes:
I think it's getting overlooked because most people don't deal with it, but I
really think we need to keep the SSL info as is.
Well, in general the *variable* parts of the banner were all put there
because of fairly urgent need, and I'd resist removing
On Fri, 18 Apr 2008 00:42:06 -0400
Tom Lane [EMAIL PROTECTED] wrote:
I'm +1 for cutting that down to a single line. I don't care one way
or the other about providing a .psqlrc option to suppress it
altogether.
Peter do you want to run with this, or would you mind if I worked up a
patch?
100 matches
Mail list logo
