On Mon, Aug 06, 2001 at 06:00:40PM +0200, Peter Eisentraut wrote:
> Karel Zak writes:
>
> > $ make install prefix=/home/PG_DEVEL/X/
>
> > cp: cannot create regular file
> > /usr/lib/postgresql/share/locale/de/LC_MESSAGES/#
>
> I have fixed this. Note, however, that this probably won't do what
At 07:02 PM 06-08-2001 -0400, Tom Lane wrote:
>pseudo-type should generate an int8 instead of int4 column. On
>compatibility grounds, it might be better to leave it generating int4,
>and invent a second pseudo-type SERIAL8 that is just the same except
>for making an int8 column. I'm more worried
Hi guys,
Just wondering if we are going to release a version 7.1.3 or not?
Regards and best wishes,
Justin Clift
--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competi
Mike Mascari <[EMAIL PROTECTED]> writes:
> I was wondering in the past if it would simply be better to have an
> .SQL script which is submitted to the template1 database at
> post-initdb time with COMMENT ON statements to document built-in
> types, functions, system relations, etc.
The nice thing
Tom Lane wrote:
>
> Presently, we have hand-assigned OIDs running up to about 1950
> (according to the unused_oids script). The range up to 16K is reserved
> for hand-assigned OIDs, and the OID counter starts at 16384 at initdb.
> A peek in pg_database shows datlastsysoid = 18931 in current sour
> What bothers me about this scheme is that genbki.sh can only create
> pg_description entries for objects with hand-assigned OIDs. It
> processes the DESCR() macro by emitting the OID of the last DATA macro,
> along with the description text, into a data file that's eventually
> copied into pg_d
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> The latest patch we submitted to the fulltextindex module improved lots of
> things but something we could not get to work was the apparently correct use
> of the PG_GETARG* macros, etc.
> Whenever we used these macros, we always got 0 or NU
Presently, we have hand-assigned OIDs running up to about 1950
(according to the unused_oids script). The range up to 16K is reserved
for hand-assigned OIDs, and the OID counter starts at 16384 at initdb.
A peek in pg_database shows datlastsysoid = 18931 in current sources, so
a total of about 25
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Hmm. How far away are we from doing SERIAL in a way that you find more
> acceptable than the current technique of mucking around internally with
> sequences and default values?
I'd say "won't happen for 7.2", whereas it seems like changing sequences
t
Peter Eisentraut wrote:
>
> Hiroshi Inoue writes:
>
> > I'm not familiar with non_ASCII locale.
> > Is 'ss' always guaranteed to be LIKE 's%' for example ?
>
> Yes. LIKE doesn't use any collation rules, since it doesn't do any
> collating.
>
Hmm I see the description like the following in S
"Roderick A. Anderson" <[EMAIL PROTECTED]> writes:
> On Mon, 6 Aug 2001, Tom Lane wrote:
>> Hmm. That's a possibility. There's some potential for trouble if an
>> application is expecting an int4 result from "SELECT nextval()" and
>> gets int8 instead, but if we think we could live with that...
Giles Lean <[EMAIL PROTECTED]> writes:
> Implementations of strxfrm() that I've looked at have had result data
> that is three or four times larger than then input string -- quite a
> penalty in some situations.
Especially so given that we don't have TOAST for indexes, so the indexed
value can't
On Mon, 6 Aug 2001, Tom Lane wrote:
> Hmm. That's a possibility. There's some potential for trouble if an
> application is expecting an int4 result from "SELECT nextval()" and
> gets int8 instead, but if we think we could live with that...
I assume there will be the same limitations as you men
[ I realise the discussion has left strxfrm(), but for the archives
if nothing else ... ]
Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> We'd need to implement the strxfrm() function in SQL and the $<=$
> operator, both of which are trivial. The index would have to be in terms
> of strxfrm().
Tom Lane wrote:
> * How should one invoke nextval() and friends on such a sequence?
> Directly applying the existing convention, eg, nextval('sequencename'),
> won't work because those functions are declared to return int4. One
I'm not really a hacker, but why couldn't you simply change nextval
Allan Engelhardt <[EMAIL PROTECTED]> writes:
> I'm not really a hacker, but why couldn't you simply change nextval to
> return int8 in all cases?
Hmm. That's a possibility. There's some potential for trouble if an
application is expecting an int4 result from "SELECT nextval()" and
gets int8 ins
Could we modify the Relation structure to hold an Oid counter? So every where
Postgres calls "newoid(void)" it gets changed to pass the relation structure it
will be associated with, i.e. newoid(Relation *). That way, every relation
could have its own counter, AND perhaps its own spinlock. Relatio
This was discussed on pgsql-general a little bit on 21-July, but the
discussion died off without reaching a conclusion. I'd like to
put out a concrete proposal and see if anyone has objections.
1. SUM() and AVG() for int2 and int4 inputs should accumulate the
running sum as an INT8, not a NUMERI
I have been thinking about implementing int8-based sequences to go along
with the existing int4-based ones. The amount of code involved doesn't
seem very large, but there are some interesting questions about the API.
Some points for discussion:
* On machines that don't offer an 8-byte-int C data
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> We have five different expected files for the int2 and int4 tests because
> every system has a different idea on what to print for ERANGE. I'm about
> to add another version. Would it make more sense to hard code one wording
> and not use strerror h
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> On the other hand, LIKE *is* multibyte aware. So the hypothetical
>> non-locale-aware comparison operators would need to be aware of
>> multibyte character sets even though not aware of locale. And the
>> "add one" operator that
mlw <[EMAIL PROTECTED]> writes:
> Am I being overly simplistic?
Yes. For one thing, Relation structs are *not* shared, nor even
persistent (the relcache will happily discard them). For another, you
haven't mentioned how we keep the counter up-to-date across system
restarts.
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> >> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Wait, why isn't that the solution in the first place. Let's build the
> > index with an opclass that uses plain strcmp compa
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>> Since bid is not in an index the evaluation of usability obviously
>> should not be based on index ops ?
Actually, now that I think about it, there's no reason that the prover
couldn't try a simple equal() on a WHERE clause and predicate
Karel Zak writes:
> $ make install prefix=/home/PG_DEVEL/X/
> cp: cannot create regular file
> /usr/lib/postgresql/share/locale/de/LC_MESSAGES/#
I have fixed this. Note, however, that this probably won't do what you
want anyway, because the compiled-in path references will still use the
prefix
Tom Lane wrote:
>
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > One of the problems I saw, and that's probably why we don't
> > have a proposal yet, is, that the size of the data is
> > recorded in the toast reference held in the main tuple. If
> > you later open the to
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> Since bid is not in an index the evaluation of usability obviously
> should not be based on index ops ?
Feel free to reimplement the theorem-prover, taking special care to
be able to prove things about operators that you have zero informa
> > test=# create index myindex on accounts(aid) where bid <> 0;
>
> > Hmm ? Am I reading correctly ? a restriction that is on a field,
that
> > is not in the index ? Does that make sense ?
>
> Yes it does, and in fact it's one of the more important applications
of
> partial indexes. It's the
Jan Wieck <[EMAIL PROTECTED]> writes:
> One of the problems I saw, and that's probably why we don't
> have a proposal yet, is, that the size of the data is
> recorded in the toast reference held in the main tuple. If
> you later open the toast value for writing, you'll
Zeugswetter Andreas SB SD wrote:
>
> > It seems to me, I guess and others too, that the OID mechanism should
> be on a
> > per table basis. That way OIDs are much more likely to be unique, and
> TRUNCATE
> > on a table should reset it's OID counter to zero.
>
> Seems to me, that this would be no
mlw wrote:
>
> Zeugswetter Andreas SB SD wrote:
> >
> > > It seems to me, I guess and others too, that the OID mechanism should
> > be on a
> > > per table basis. That way OIDs are much more likely to be unique, and
> > TRUNCATE
> > > on a table should reset it's OID counter to zero.
> >
> > Seem
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I keep bugging Jan about it, since pre-7.1 and no one has come up with
> > an idea.
>
> Well, if you want an idea:
>
>BEGIN;
>
>SELECT open_toast_object(toastable_column) FROM tab WHERE ...;
>
>-- app checks that it got ex
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I agree we should have it, but I thought the problem was that we
> > couldn't come up with an API that worked.
>
> AFAIR, no one's really tried yet. I do not recall any proposals
> getting shot down ...
One of the problems I s
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
>> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Wait, why isn't that the solution in the first place. Let's build the
> index with an opclass that uses plain strcmp comparison.
> Do we have to make 2 indexes for non_ASCII text field ?
You would if you
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> test=# create index myindex on accounts(aid) where bid <> 0;
> Hmm ? Am I reading correctly ? a restriction that is on a field, that
> is not in the index ? Does that make sense ?
Yes it does,
Hi,
the NLS is failed for:
$ make install prefix=/home/PG_DEVEL/X/
.
.
[cut]
.
.
for lang in de; do \
/bin/sh ../../../config/install-sh -c -m 644 $lang.mo
/usr/lib/postgresql/share/locale/$lang/LC_MESSAGES/postgres.mo || exit 1; \
done
cp: cannot create regular file
/usr/lib/post
On Mon, 6 Aug 2001, mlw wrote:
> Zeugswetter Andreas SB SD wrote:
> >
> > > It seems to me, I guess and others too, that the OID mechanism should
> > be on a
> > > per table basis. That way OIDs are much more likely to be unique, and
> > TRUNCATE
> > > on a table should reset it's OID counter to
Zeugswetter Andreas SB SD wrote:
>
> > It seems to me, I guess and others too, that the OID mechanism should
> be on a
> > per table basis. That way OIDs are much more likely to be unique, and
> TRUNCATE
> > on a table should reset it's OID counter to zero.
>
> Seems to me, that this would be no
On Mon, 6 Aug 2001, mlw wrote:
> I think you are focusing too much on "ROWID" and not enough on OID. The issue
> at hand is OID. It is a PostgreSQL cluster wide limitation. As data storage
> decreases in price, the likelihood of people running into this limitation
> increases. I have run into OID
> It seems to me, I guess and others too, that the OID mechanism should
be on a
> per table basis. That way OIDs are much more likely to be unique, and
TRUNCATE
> on a table should reset it's OID counter to zero.
Seems to me, that this would be no different than a performance improved
version
of
Grant wrote:
>Is it at all possible to use vim to interact with psql to
>provide input?
Why are you asking this on hackers? Please read
http://www.postgresql.org/devel-corner/ ("YOU MUST TRY ELSEWHERE
FIRST")
Yes, psql can call vim. Its in the user documentation. You may
want to read that too.
I think you are focusing too much on "ROWID" and not enough on OID. The issue
at hand is OID. It is a PostgreSQL cluster wide limitation. As data storage
decreases in price, the likelihood of people running into this limitation
increases. I have run into OID problems in my curent project. Geez, 40
> Even more to the point, those typical installations do not want
> exclusive-locked VACUUM. Haven't you paid any attention to the user
> complaints we've been hearing for the last N years? People want a
> nonexclusive VACUUM (or no VACUUM at all, but that's not a choice we
can
> offer them now
Quoting Alex Pilosov <[EMAIL PROTECTED]>:
> I'm working on this (not plpgsql specific, though).
>
> I have most of this done, just need to merge it to the -current and send
> in the patch, but I was bogged down by RL :(
Problem is that I'd REALLY would like a workaround in 7.1... I have 7.2 fro
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > test=# create index myindex on accounts(aid) where bid <> 0;
Hmm ? Am I reading correctly ? a restriction that is on a field, that
is not in the index ? Does that make sense ? (aid --> bid)
> The original implementation would have refused to let y
Tom Lane wrote:
>
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Wait, why isn't that the solution in the first place. Let's build the
> > index with an opclass that uses plain strcmp comparison.
>
> By George, I think you've got it! All we need is comparison ops and
> an opclass that use s
46 matches
Mail list logo
