Andrew Dunstan wrote:
>
> Thanks. I will attend to most of this. A couple of points:
>
> . using "wb" for writing out on Windows is so that we don't get Windows'
> gratuitous addition of carriage returns. I will document that.
> . I can't use do { stuff; } while(0) for a macro that does declarat
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Doesn't pg_indent do the spacing for us when code is merged?
For the most part it will. You can ask Bruce to run the code through it
for you if you don't have BSD indent handy.
regards, tom lane
---(end
Thanks. I will attend to most of this. A couple of points:
. using "wb" for writing out on Windows is so that we don't get Windows'
gratuitous addition of carriage returns. I will document that.
. I can't use do { stuff; } while(0) for a macro that does declarations
- the declarations would be l
Andrew Dunstan writes:
> New version has passed basic Windows tests, and is available (with new
> Makefile too) at http://www.dunslane.net/~andrew/Initdb_In_C.html
>
> constructive comments (very) welcome.
That looks very nice. Just some nitpicking comments. (Most of these
comments should be ex
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I think we should change the "check_function_bodies" to something more
> > general. I like "restore_validation_mode" because it could also be used
> > to disable foreign key checks which we are discussing.
>
> I think I'd prefer to k
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think we should change the "check_function_bodies" to something more
> general. I like "restore_validation_mode" because it could also be used
> to disable foreign key checks which we are discussing.
I think I'd prefer to keep foreign key check disabl
Fabrizio Mazzoni wrote:
Resending because i did not attahc the file .. !! Sorry for the mistake...
Hello,
I just translated the psql.pot file into Italian language and tested it in 7.4beta3. It seems to
work just fine. The "it" language is not in the nls.mk so it must be added. I don't
know i
Below is a 7.2.4 example of the rserv log with inet data type. You will
notice that inet cast to text, and the log entry are differently (one
from unknown directly to text via a trigger, the other from inet cast to
text).
I see this hasn't been changed in the 7.4 version. Is there intent on
removi
James Rogers wrote:
> While these should generate some performance improvements on smaller
> databases, more important to me is that it will go along way to making
> it scale more like Oracle when dealing with very large and active
> systems (my current problem). It has been a few years, but I've d
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Peter Eisentraut wrote:
> >> Given that new languages don't tend to appear out of the blue, I think
> >> it's reasonable to design the feature considering the languages currently
> >> available.
>
> I think that position is sufficient
Hi,
I've been going through the source tree (pretty nice, BTW) and have
found a number of things I'd like to work on. My primary interest is in
adding performance and scalability features to the underlying engine.
However, one thing I haven't found is a roadmap/schedule for major
architectural f
- Original Message -
From: "Andrew Dunstan" <[EMAIL PROTECTED]>
> Yes, but when I asked that question at least one voice piped up (Debian
> package maintainer, I think) to say that these were still needed as
> standalone programs. However, I have already replaced the calls I
> previously
Bruce Momjian wrote:
P O S T G R E S Q L
7 . 4 O P E NI T E M S
Current at ftp://momjian.postgresql.org/pub/postgresql/open_items.
On the same folder there is: PITR_20020822_02.gz
tell me that we are near to have it :-)
Regards
Gaet
On Mon, 2003-10-06 at 21:31, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > I currently use pg_encoding in Debian's automatic upgrade script to
> > extract the existing default encoding from pg_database, thus:
> > $ psql -q -t -d template1 -c "select encoding from pg_database whe
Oliver Elphick <[EMAIL PROTECTED]> writes:
> I currently use pg_encoding in Debian's automatic upgrade script to
> extract the existing default encoding from pg_database, thus:
> $ psql -q -t -d template1 -c "select encoding from pg_database where
> datname = 'template1'"
> 0
> and then I
Hello,
It seems to me that the below should not be able to happen.
postgres=# create user with encrypted password '98wq7912a';
CREATE USER
postgres=# create user with encrypted password '98wq7912a';
ERROR: CREATE USER: user name "with" already exists
Sincerley,
Joshua D. Drake
--
Command Pr
Oliver Elphick wrote:
On Mon, 2003-10-06 at 19:30, Peter Eisentraut wrote:
About pg_encoding. There is currently no way to tell whether an encoding
exists. Normally you would put this kind of thing into a system table,
but doing that is a bit tricky with the encodings. I would like to see
p
On Mon, 2003-10-06 at 19:30, Peter Eisentraut wrote:
> About pg_encoding. There is currently no way to tell whether an encoding
> exists. Normally you would put this kind of thing into a system table,
> but doing that is a bit tricky with the encodings. I would like to see
> pg_encoding go, so
On 24 Sep, Greg Stark wrote:
> Ok, I guess I misunderstood you. These queries are taking 0.5ms - 300ms except
> for the last aggregate query which takes just over 1s.
http://developer.osdl.org/markw/dbt2-pgsql/120/
I have more data where I got the response times for each transaction
much lower by
Peter Eisentraut wrote:
About pg_encoding. There is currently no way to tell whether an encoding
exists. Normally you would put this kind of thing into a system table,
but doing that is a bit tricky with the encodings. I would like to see
pg_encoding go, so let's hear what information people ne
Rod Taylor <[EMAIL PROTECTED]> writes:
> Rather than running ANALYZE, how about simply dumping out and restoring
> current statistics?
Nope. That would assume that the stats are the same across revisions.
Not to mention requiring superuser privileges.
regards, tom lane
-
> It almost certainly would, but I was assuming we had to consider this in
> the context of loading existing dump files. We could think about having
> pg_dump emit an automatic ANALYZE after the data loading step in the
> future though.
Rather than running ANALYZE, how about simply dumping out an
"monu_indian" <[EMAIL PROTECTED]> writes:
> I have designed a new indexing tecknique for biological database now I want to
> implement it in pgsql so what the work I will have to do? From where I should start?
You could write a new index access method ... though I would not exactly
recommend that
Rainer Klute <[EMAIL PROTECTED]> writes:
> Here's an Oracle example:
> create table BUSINESS_PROCESS
> (ID NUMBER not null primary key,
> BUSINESS_PROTOCOL varchar2(254),
> PROTOCOL_VERSION varchar2(254),
> DEFAULT_CONVERSATION_TIMEOUT NUMBER);
Oh, just another
Andrew Dunstan writes:
> Yes, but when I asked that question at least one voice piped up (Debian
> package maintainer, I think) to say that these were still needed as
> standalone programs. However, I have already replaced the calls I
> previously had to these from the C version (pg_id a few days
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Does an ANALYZE run between index creation and bulk FK checking improve
> > planning?
>
> It almost certainly would, but I was assuming we had to consider this in
> the context of loading existing dump files. We could think about having
I have designed a new indexing tecknique for biological database now I want to
implement it in pgsql so what the work I will have to do? From where I should start?
Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy The Best In BOOKS at http://www.bestsellers.indiati
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
However, from an initdb POV I am assuming that we are only interested in
the name=>number conversion, even though initdb.sh does no apparent
checking on the parameter it is passing to pg_encoding. Please tell me
if this is incorrect.
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> However, from an initdb POV I am assuming that we are only interested in
> the name=>number conversion, even though initdb.sh does no apparent
> checking on the parameter it is passing to pg_encoding. Please tell me
> if this is incorrect.
That's cor
pg_encoding appears to have 2 personalities, (name=>number and vice
versa) depending on whther or not its parameter begins with a digit
(which is in itself fragile - what if you gave it "3foo"?).
However, from an initdb POV I am assuming that we are only interested in
the name=>number conversio
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Anyone see a better way?
> Maybe just run one loop and try pairs of (shared_buffers, max_connections):
> (1000, 100) (800, 50) (600, 40) (400, 30) (200, 20) (50, 10)
Hmm ... that wouldn't work real well as-is, because if max_conne
Tom Lane writes:
> Perhaps we should avoid all attempts at cuteness and just run the
> initial probes for workable shared_buffers with max_connections=20,
> as well as making that be the minimum max_connections value probed for.
>
> Anyone see a better way?
Maybe just run one loop and try pairs o
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Does anyone know why 'pg_restore -d' doesn't display the commands being
> > executed, like you see when you don't use '-d':
>
> > pg_restore < /tmp/test.db
> > pg_restore -d test < /tmp/test.db
>
> The first sends a script to
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
initdb is kinda hokey, again probably for historic reasons, and that if
it were being redesigned from scratch today a better way would be to
have an cluster image built at compile time and just copied and tweaked
at runtime. Almost a
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> initdb is kinda hokey, again probably for historic reasons, and that if
> it were being redesigned from scratch today a better way would be to
> have an cluster image built at compile time and just copied and tweaked
> at runtime. Almost all the requi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Does anyone know why 'pg_restore -d' doesn't display the commands being
> executed, like you see when you don't use '-d':
> pg_restore < /tmp/test.db
> pg_restore -d test < /tmp/test.db
The first sends a script to stdout (effectively equival
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I guess it ain't broke so it doesn't need
to be fixed, so I'm not sure if it would be worth it.
That's about my feeling. There's nothing wrong with the initdb process,
other than its dependency on shell scripting, and so no visib
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I guess it ain't broke so it doesn't need
> to be fixed, so I'm not sure if it would be worth it.
That's about my feeling. There's nothing wrong with the initdb process,
other than its dependency on shell scripting, and so no visible gain to
be had by
Does anyone know why 'pg_restore -d' doesn't display the commands being
executed, like you see when you don't use '-d':
pg_dump -Fc test >/tmp/test.db
pg_restore < /tmp/test.db
pg_restore -d test < /tmp/test.db
The first pg_restore displays the commands, while the second d
Andrew Dunstan writes:
> I might. :-) Actually, it has struck me that the way we go about doing
> initdb is kinda hokey, again probably for historic reasons, and that if
> it were being redesigned from scratch today a better way would be to
> have an cluster image built at compile time and just co
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> I notice you cannot COMMENT ON the following:
> * Cast
> * Conversion
> * Operator class
> Is that a deliberate omission, or is it an oversight?
Unimplemented feature AFAIR. BTW, if you feel like doing something
about this, COMMENT ON LARGE OB
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Shouldn't this be a WARNING or an ERROR? Trying to create a table
> WITHOUT OIDS that inherits from a table WITH OIDS silently ignores the
> WITHOUT OIDS specification. It think that should be a warning...
I'm not convinced. You might as w
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Is there any reason other than historical that the System Views setup
isn't a separate script fed to postgres by initdb, like, say, the
information schema file? If there isn't a good reason should we unwire
it as part of moving to a
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Oh, that makes me feel better. Do we have timings for this code?
This is just a single data point, but I made a table of 1 million
rows containing just the int4 primary key column (values 0-1million
in a somewhat random order). Then I cop
Jan Wieck <[EMAIL PROTECTED]> writes:
> Does an ANALYZE run between index creation and bulk FK checking improve
> planning?
It almost certainly would, but I was assuming we had to consider this in
the context of loading existing dump files. We could think about having
pg_dump emit an automatic A
Jan Wieck <[EMAIL PROTECTED]> writes:
> I'm not sure what conditions could possibley cause SPI_prepare to return
> NULL, but it'd be certainly better to check that.
Good thought. I was looking at the other SPI_prepare calls in
ri_triggers.c, which don't check for NULL either, but clearly they
sh
Bruce Momjian wrote:
Wow, that's a heap of code --- that's my only comment. :-)
Not really.
I'm not sure what conditions could possibley cause SPI_prepare to return
NULL, but it'd be certainly better to check that. Other than that, looks
good to me.
Jan
---
Tom Lane wrote:
PS: please don't send stuff bcc to pgsql-hackers. I was fortunate to
notice this in my probable-spam folder before deleting it ...
Yeah, that was a fat finger mistake.
cheers
andrew
---(end of broadcast)---
TIP 6: Have you se
Hi,
I notice you cannot COMMENT ON the following:
* Cast
* Conversion
* Operator class
Docs:
http://developer.postgresql.org/docs/postgres/sql-comment.html
Is that a deliberate omission, or is it an oversight? If it's
deliberate, it seems kind of arbitrary. Or have the docs just not been
upda
On 4/10/03 8:10 pm, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> I said:
>> Hm. The parallel regression tests require at least 20. I deliberately
>> allowed initdb to select values as small as 10 on the theory that
>> installing and not being able to run the parallel regression tests is
>> better tha
On Sun, Oct 05, 2003 at 05:51:47PM -0400, Andrew Dunstan wrote:
> Perhaps we need a function or two to convert pre-gregorian dates to
> gregorian dates and vice versa, with the cutover date either a
> configuration variable (default the 1752 date) or a parameter of the
I guess that's one of the
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> But I wonder how this squares with the SQL spec...
> The root of this problem is that revoking privileges from the owner
> doesn't square with the SQL spec in the first place. Allowing having a
> grant option without the privilege
Hi,
Shouldn't this be a WARNING or an ERROR? Trying to create a table
WITHOUT OIDS that inherits from a table WITH OIDS silently ignores the
WITHOUT OIDS specification. It think that should be a warning...
test=# create table a (a int4);
CREATE TABLE
test=# create table c () inherits (a) with
53 matches
Mail list logo
