> > Storing everything as Unicode is not a good idea, actually. First,
> > Unicode tends to consume more storage space than other character
> > sets. For example, UTF-8, one of the most commonly used encoding for
> > Unicode consumes 3 bytes for Japanese characters, while SJIS only
> > consumes 2
mlw <[EMAIL PROTECTED]> writes:
> Aside from adding %llu to all the %u everywhere an OID is used in a
> printf, and any other warnings, are there any other things I should be
> specially concerned about?
FE/BE protocol, a/k/a client/server interoperability. Flagging a
database so that a backend
On Tue, 14 Aug 2001, Tatsuo Ishii wrote:
> Storing everything as Unicode is not a good idea, actually. First,
> Unicode tends to consume more storage space than other character
> sets. For example, UTF-8, one of the most commonly used encoding for
> Unicode consumes 3 bytes for Japanese character
* mlw <[EMAIL PROTECTED]> [010813 21:06]:
> I am thinking about embarking on changing the typedef of OID to unsigned long
> long.
>
> My plan is to make it conditional at configure time, i.e.
>
> #ifdef OID_ULONGLONG
> typedef unsigned long long Oid;
> #define OID_MAX ULLONG_MAX
> #else
> typed
Is there a bug listing for PostgreSQL somewhere?
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
I am thinking about embarking on changing the typedef of OID to unsigned long
long.
My plan is to make it conditional at configure time, i.e.
#ifdef OID_ULONGLONG
typedef unsigned long long Oid;
#define OID_MAX ULLONG_MAX
#else
typedef unsigned int Oid;
#define OID_MAX UINT_MAX
#endif
Aside f
Horst Herb <[EMAIL PROTECTED]> writes:
> On Tuesday 14 August 2001 02:25, you wrote:
>> I still think that expanding transaction IDs (XIDs) to 8 bytes is no help.
> But what about all of us who need to establish a true long term audit trail?
> For us, still the most elegant solution would be a q
On Tuesday 14 August 2001 02:25, you wrote:
> I still think that expanding transaction IDs (XIDs) to 8 bytes is no help.
> Aside from portability and performance issues, allowing pg_log to grow
> without bound just isn't gonna do. So, the name of the game is to recycle
But what about all of us
> > It'd be even nicer if you could make a table that has, say, one column
> > utf8 (or utf32 even), one column euc-jp and one column shift-jis, so
> > that you could cache format conversions.
>
> This might be a nice thing to show off but I'm not sure about the
> practical use. There's Unicode
Dave Blasby wrote:
>
> The next question is, of course, what does 'semi-compliant' mean? Or,
> more interesting, why would you want a semi-compliant database? For
> most people's simple tasks, the built in geometry types are adequate.
> Those interested in doing more complex tasks will probably
Tom Lane wrote:
>
> Dave Blasby <[EMAIL PROTECTED]> writes:
> > [snip] Vivid Solutions (cf.
> > http://www.vividsolutions.com/jts/jtshome.htm) will be releasing it
> > under the LGPL.
> > [snip]
> > This leaves the option for creating a semi-compliant OpenGIS core inside
> > PostgreSQL and having
Dave Blasby <[EMAIL PROTECTED]> writes:
> [snip] Vivid Solutions (cf.
> http://www.vividsolutions.com/jts/jtshome.htm) will be releasing it
> under the LGPL.
> [snip]
> This leaves the option for creating a semi-compliant OpenGIS core inside
> PostgreSQL and having a LGPL add-on for the complex sp
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I am tempted to replace all attempts to build text data on your own (with
> VARDATA, VARHDRSZ, etc.) with proper calls to textin/textout in all places
> that can't claim to be truly internal (especially all contrib).
Other than contrib, what places d
I think it would be great for PostgreSQL to be an 'OpenGIS Simple
Feature Specification for SQL' compliant database with robust spatial
operators right-out-of-the-box.
Currently, PostGIS implements most of the OpenGIS specification. The
unimplemented portions are the important; spatial operator
I am tempted to replace all attempts to build text data on your own (with
VARDATA, VARHDRSZ, etc.) with proper calls to textin/textout in all places
that can't claim to be truly internal (especially all contrib). The
background is that the internal format might change sometime when more
locale fe
I wrote:
> 3. As a separate proposal, we could change COUNT()'s running counter
> and output datatype from INT4 to INT8. This would make it a little
> slower but effectively overflow-proof.
> * Changing the output datatype of these operations --- especially COUNT
> --- might affect or even break
Bruce Momjian wrote:
>
> > Tom Lane wrote:
> > >
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > >> current list of 7.1.2 -> 7.1.3 changes. Bruce, are you going to handle
> > > >> the documentation updates and release branding?
> > >
> > > > Yes, just tell me when to start.
> > >
> > > I do
> [EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes:
> > That's a couple of days ago now... anything happening?
>
> Bruce is evidently waiting on Hiroshi's confirmation that he's done
> applying his back-patches. I believe he is, though; he did apply
> what I thought was the pa
[EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes:
> That's a couple of days ago now... anything happening?
Bruce is evidently waiting on Hiroshi's confirmation that he's done
applying his back-patches. I believe he is, though; he did apply
what I thought was the patch he had i
> Something I would like Dave to comment on is how cleanly we can split
> the object/indexing from the OpenGIS spec'ed support tables and
> reference systems. I am thinking about the canonical representation in
> particular, which could be pretty ugly with the SRS id's hanging in
> there for no pu
Tom Lane wrote:
>
> [ why is this thread hiding in -patches? It should be on -hackers or
> -general, methinks. ]
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Let me suggest a solution. What if we took the part of the GIS code
> > that duplicated our existing code (geometric types) and r
Tom Lane <[EMAIL PROTECTED]> writes:
> Another bug report complaining of include file name conflicts came in
> just now. The only solution I can see is to rename config.h to
> something more project-specific. Should we do this, or keep ignoring
> the problem?
I would vote for renaming it. I'v
Neil Padgett <[EMAIL PROTECTED]> writes:
> mlw wrote:
>> The way I see it there are 4 options for the OID:
> [snip]
>> (2) Allow the ability to have tables without OIDs. This is a source of
>> debate.
> I think Tom Lane has already committed some patches to allow for this.
> So, I think you shoul
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Another problem in all of this is that even if you hide the config.h
> sufficiently, you'll end up including it anyway of course, and more likely
> than not you will have a symbol clash with what the user wants to define
> in his config.h file.
This
mlw wrote:
> The way I see it there are 4 options for the OID:
[snip]
> (2) Allow the ability to have tables without OIDs. This is a source of
> debate.
I think Tom Lane has already committed some patches to allow for this.
So, I think you should be able to try this from the latest CVS. (Tom?)
"gabriel" <[EMAIL PROTECTED]> writes:
> hello all
>
> I have a perl script that read a text file and
> insert the data in a table...
>
> but when this script is runing the usage of CPU by postmaster grows to
> between 79 and 90 percent...
And this is a problem because... ?
Honestly, you're
mlw <[EMAIL PROTECTED]> writes:
> Somehow I guess I created a misunderstanding. I don't really care about
> ROWID. I care that OID is a 32 bit number. The notion that each table could
> have its own "OID" similar to a ROWID could be an intermediate solution. I
> have flip-flopped a couple times a
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Things like VACUUM and ANALYZE, which you will have to keep unless you
> want to implement an Oracle storage manager as well. ;-)
Evidently Ian is just interested in a parser that could be used by
Oracle-compatible applications, which'd not be invoki
Ian Lance Taylor writes:
> I'm not sure what you mean by managing grammar changes, although
> perhaps I am reading too much into that. The Oracle grammar is set by
> Oracle, and will not change even if the Postgres grammar changes.
Things like VACUUM and ANALYZE, which you will have to keep unl
Tom Lane <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > ... most of the cost will be paid by the people who care about
> > it. (Not all of the cost, because some communication will be required
> > when the parse tree nodes are changed.)
>
> > Along these lines, I
Tom Lane writes:
> Another bug report complaining of include file name conflicts came in
> just now. The only solution I can see is to rename config.h to
> something more project-specific. Should we do this, or keep ignoring
> the problem?
Another problem in all of this is that even if you hid
Alex Avriette <[EMAIL PROTECTED]> writes:
> Dont beat yourself up, guys, over making postgres a drop-in replacement for
> Oracle. The people that would benefit from actually "dropping in" postgres
> into an Oracle install will have already eased the burden on themselves by
> being responsible in
On Monday 13 August 2001 23:26, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I vote for ignore. Don't tons of projects have a config.h file?
>
> That's exactly why there's a problem. We are presently part of the
> problem, not part of the solution.
The solution usually to hav
> 3. VACUUM will have the responsibility of replacing old normal XIDs with
> FrozenXID. It will do this whenever a committed-good tuple has xmin less
> than a cutoff XID. (There is no need to replace xmax, since if xmax is
> committed good then the tuple itself will be removed.) The cutoff XID
Tom Lane wrote:
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > It's possible for a function to use a unique snapshot
> > if there are only SELECT statements in the function
> > but it's impossible if there are UPDATE/DELETE or
> > SELECT .. FOR UPDATE statements etc.
>
> You are confusing
N
Jan Wieck <[EMAIL PROTECTED]> writes:
> If we want to have both parsers available at runtime we need
> to replace the YY (case-insensitive) prefix in the generated
> files per parser and call the right one from tcop. Now for
> some flex/bison combo's at least the prefix switc
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I vote for ignore. Don't tons of projects have a config.h file?
That's exactly why there's a problem. We are presently part of the
problem, not part of the solution.
regards, tom lane
---(end of broadc
Tom Lane wrote:
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > It's possible for a function to use a unique snapshot
> > if there are only SELECT statements in the function
> > but it's impossible if there are UPDATE/DELETE or
> > SELECT .. FOR UPDATE statements etc.
>
> You are confusing
N
This is an attempt to flesh out the ideas of my earlier proposal
(http://fts.postgresql.org/db/mw/msg.html?mid=67786) into a complete
description of how things should work. It's still largely the same
proposal, but I have adopted a couple of the ideas from the followup
discussion --- notably Vadi
> Another bug report complaining of include file name conflicts came in
> just now. The only solution I can see is to rename config.h to
> something more project-specific. Should we do this, or keep ignoring
> the problem?
I vote for ignore. Don't tons of projects have a config.h file?
--
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> >> that plpgsql's handling of command-counter changes is broken, but it
> >> does not follow that sprinkling the code with SetQuerySnapshot is wise.
>
> > Why do you blame PL/pgSQL for that? I don't see a single
> > reference t
hello all
I have a perl script that read a text file and
insert the data in a table...
but when this script is runing the usage of CPU by postmaster grows to
between 79 and 90 percent...
there's something to do about it?
thanks...
---(end of broadcast)--
> Tom Lane wrote:
> >
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > >> current list of 7.1.2 -> 7.1.3 changes. Bruce, are you going to handle
> > >> the documentation updates and release branding?
> >
> > > Yes, just tell me when to start.
> >
> > I don't know of any reason to wait... anyo
Another bug report complaining of include file name conflicts came in
just now. The only solution I can see is to rename config.h to
something more project-specific. Should we do this, or keep ignoring
the problem?
regards, tom lane
---(end of br
Jan Wieck <[EMAIL PROTECTED]> writes:
> files per parser and call the right one from tcop. Now for
> some flex/bison combo's at least the prefix switches (to have
> something different than YY) don't work reliable. There will
> be some global YY-objects left, causing linkag
I sent the list a message a little while ago about what I do with postgres.
I thought, after all this discussion, that it might be important to send a
further message to the list indicating why I chose not to use Oracle.
I'm going to go out on a limb and say that I have one of the largest
postgre
Somehow I guess I created a misunderstanding. I don't really care about
ROWID. I care that OID is a 32 bit number. The notion that each table could
have its own "OID" similar to a ROWID could be an intermediate solution. I
have flip-flopped a couple times about whether or not the OID being able t
Jan Wieck <[EMAIL PROTECTED]> writes:
>> that plpgsql's handling of command-counter changes is broken, but it
>> does not follow that sprinkling the code with SetQuerySnapshot is wise.
> Why do you blame PL/pgSQL for that? I don't see a single
> reference to the command counter from
Tom Lane wrote:
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > It's possible for a function to use a unique snapshot
> > if there are only SELECT statements in the function
> > but it's impossible if there are UPDATE/DELETE or
> > SELECT .. FOR UPDATE statements etc.
>
> You are confusing snaps
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> ... most of the cost will be paid by the people who care about
> it. (Not all of the cost, because some communication will be required
> when the parse tree nodes are changed.)
> Along these lines, I don't think Bruce's suggestion of modifications
>
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> It's possible for a function to use a unique snapshot
> if there are only SELECT statements in the function
> but it's impossible if there are UPDATE/DELETE or
> SELECT .. FOR UPDATE statements etc.
You are confusing snapshots (which determine visibil
Ian Lance Taylor wrote:
> Along these lines, I don't think Bruce's suggestion of modifications
> to the Postgres gram.y is a good idea, because it causes the Oracle
> parser to add an ongoing cost to the Postgres parser.
Bruce, Tom and I discussed these issues during our time in
San Di
> Some other databases have the notion of a ROWID which uniquely
identifies a row
> within a table. OID can be used for that, but it means if you use it,
you must
> limit the size of your whole database system.
Imho that is getting it all wrong. OID is *not* a suitable substitute
for other
db's
>> Included is a example program appears in our docs (libpq.sgml).
If you're going to do any work on that example, how about transforming
it into something useful, ie, a more realistic example of using NOTIFY.
It should be using a select() to wait for input, not a sleep() loop.
As for the clean
Hi Vince,
The point I'll make is this :
People who presently have installations on Oracle will be more inclined
to test/trial PostgreSQL if they know the learning curve is much less
than say, migrating to DB2 would be (or some other database without
specific Oracle-transition compatibilities).
On Mon, 13 Aug 2001, Tatsuo Ishii wrote:
> Included is a example program appears in our docs (libpq.sgml).
> As you can see, the very last part of the program:
>
> PQfinish(conn);
>
> return 0;
>
> never execute. Should we remove them?
Most compilers should be able to detect this and
Tatsuo Ishii wrote:
>
> > > One way to make the results equivalent is to compute a new
QuerySnapshot
> > > for each SPI query. Quite aside from the cost of doing so, I do not
> > > think it makes sense, considering that the previous QuerySnapshot must
> > > be restored when we return from the fun
57 matches
Mail list logo
