PQescapebytea() is not multibyte aware and will produce bad multibyte
character sequences. Example:
INSERT INTO t1(bytea_col) VALUES('characters produced by
PQescapebytea');
ERROR: Invalid EUC_JP character sequence found (0x8950)
I think 0x89 should be converted to '\\211' since 0x89 of 0x8950
On Fri, 5 Apr 2002, Christopher Kings-Lynne wrote:
> > > 2. Since int4 and abstime are binary compatible (ie
> > int4::abstime works), is
> > > there any serious problem with updating a pg_attribute row for
> > an int4 and
> > > changing it to and abstime? My experiments seem to work.
> >
> > A
> > A few integer values are reserved values in abstime, to allow
> > implementation of infinity, -infinity, etc.
> Does this mean that hacking the type of an int4 column to become abstime is
> a bad idea?
> Yes in theory - no in practice?
Hmm. I assume that this is in the context of an "official
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am still looking for a constructive idea on how we can get this to
> > work, rather than calling my ideas "ridiculous".
>
> We know very well how to make it work: JDBC can issue a SET timeout = 0
> after exiting the transaction. Y
> > 4. Is there any worth in me submitting a patch that will allow
> rudimentary
> > column type changing, so long as the types are binary compatible???
>
> Hmm. Seems like that case, and the various ones involving adjustment of
> char/varchar length by hacking atttypmod, would be useful to suppo
> > 2. Since int4 and abstime are binary compatible (ie
> int4::abstime works), is
> > there any serious problem with updating a pg_attribute row for
> an int4 and
> > changing it to and abstime? My experiments seem to work.
>
> A few integer values are reserved values in abstime, to allow
> impl
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I don't object to use a search path to resolve unqualified
> > function, type etc names. But it is very siginificant for
> > users to be able to be sure what tables they are handling.
>
> I really don't buy this argument; it seems
> I really don't buy this argument; it seems exactly comparable to
> arguing that the notion of current directory in Unix is evil, and
> that users should be forced to specify absolute paths to every
> file that they reference.
You know, I'm kinda surprised that the spec doesn't define a CURRENT_
> I am brazilian and work with o database PostGreSql 7.1.3.
Bom dia!
> I am upgrade PostGreSql 7.1.3 to 7.2.1 and find some bugs
> insert dataype time .
lockhart=# select time '03';
ERROR: Bad time external representation '03'
> This is a bug or new pattern ?
> The manuals show that
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> I don't object to use a search path to resolve unqualified
> function, type etc names. But it is very siginificant for
> users to be able to be sure what tables they are handling.
I really don't buy this argument; it seems exactly comparable to
arguing
I've been thinking about how to avoid performance degradation in
function and operator lookup due to the addition of namespaces.
Probing the syscaches individually for each namespace on the
search path seems like a loser, mainly because a separate indexscan
is required to load each cache entry; ev
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Oh I see but I think using the search SCHEMA path for
> > table name resolution is harmful.
>
> Huh? That's more or less the entire *point* of these changes, IMHO.
> What's harmful about having a search path?
I don't object to us
> 1. What is the difference between abstime and timestamp - they seem to
> display equally...
abstime is four bytes with a range of +/- 68 years. timestamp is eight
bytes with a range from 4212BC to way into the future.
> 2. Since int4 and abstime are binary compatible (ie int4::abstime works),
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Oh I see but I think using the search SCHEMA path for
> table name resolution is harmful.
Huh? That's more or less the entire *point* of these changes, IMHO.
What's harmful about having a search path?
regards, tom lane
---
Tom Lane wrote:
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am still looking for a constructive idea on how we can get this to
> > work, rather than calling my ideas "ridiculous".
>
> We know very well how to make it work: JDBC can issue a SET timeout = 0
> after exiting the transaction.
Tom Lane wrote:
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > Well for example,
> > how could psqlodbc driver know the CURRENT schema ?
>
> What "CURRENT" schema? If you have a search path more than one entry
> long, there is no unique notion of a CURRENT schema.
Oh I see but I think usin
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> Well for example,
> how could psqlodbc driver know the CURRENT schema ?
What "CURRENT" schema? If you have a search path more than one entry
long, there is no unique notion of a CURRENT schema.
regards, tom lane
---
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am still looking for a constructive idea on how we can get this to
> work, rather than calling my ideas "ridiculous".
We know very well how to make it work: JDBC can issue a SET timeout = 0
after exiting the transaction. You're proposing to change th
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I see. However my main problem is that the schema of unqualified
> > vs1 is affected by the existence of yamada.vs1. I don't think
> > it's a useful behavior.
>
> Well, if yo
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, I now think that saving the SET commands that are ignored in a
> > transaction and running them _after_ the transaction completes may be
> > the best thing.
>
> No, that's just plain ridiculous. If you want to change the semant
Tom Lane wrote:
>
> Fernando Nasser <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Actually that was my initial choice of name, but I changed my mind
> >> later. The reason is that the dbadmin should be able to restrict or
> >> even delete the public namespace if his usage plans for the da
Fernando Nasser <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Actually that was my initial choice of name, but I changed my mind
>> later. The reason is that the dbadmin should be able to restrict or
>> even delete the public namespace if his usage plans for the database
>> don't allow any sha
Tom Lane wrote:
>
> Fernando Nasser <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I've been vacillating about whether to choose another name for the
> >> public namespace to avoid the need for quotes here. I can't think
> >> of another good name :-(
>
> > For the special schemas, we have
Tom Lane wrote:
>
> I suppose it's a judgment call which is uglier. Thoughts?
>
Well, PUBLIC is an SQL reserved keyword (pre-92). We are
already very liberal with keywords. I would leave PUBLIC alone.
I does not _have_ to be "public", so we can just avoid the issue
by adding a pg_ prefix to
Fernando Nasser <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I've been vacillating about whether to choose another name for the
>> public namespace to avoid the need for quotes here. I can't think
>> of another good name :-(
> For the special schemas, we have pg_catalog, (pg_temp, pg_toast ?
Hiroshi Inoue wrote:
>
> I see. However my main problem is that the schema of unqualified
> vs1 is affected by the existence of yamada.vs1. I don't think
> it's a useful behavior.
>
The unqualified one is there mainly for compatibility, so you can
still use your old database set ups without sch
Tom Lane wrote:
>
> I've been vacillating about whether to choose another name for the
> public namespace to avoid the need for quotes here. I can't think
> of another good name :-(
>
For the special schemas, we have pg_catalog, (pg_temp, pg_toast ?),
so pg_public could do the trick.
--
Fern
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, I now think that saving the SET commands that are ignored in a
> transaction and running them _after_ the transaction completes may be
> the best thing.
No, that's just plain ridiculous. If you want to change the semantics
of SET, then make it wor
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I think we have only a few options:
>
> You forgot
>
> o Do nothing.
>
> IMHO the current behavior is not broken, and does not need fixed.
> All of the options you suggest are surely more broken than the current
> behavior.
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
On 3 Apr 2002, Hannu Krosing wrote:
> On Wed, 2002-04-03 at 06:52, Gavin Sherry wrote:
> > On Wed, 3 Apr 2002, Christopher Kings-Lynne wrote:
> >
> > > Hi,
> > >
> > > Would it be an idea to have pg_dump append an ANALYZE; command to the end of
> > > its dumps to assist newbies / inexperienced
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> Could you, please, comment the proposal.
Okay: "ugly and unimplementable".
Where are you going to put these back-references that the description
glosses over so quickly? They can't be in the row itself; that doesn't
scale to large numbers of reference
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> 3. Is there any way of checking pg_type to check that two types are binary
> compatible and can be substiuted in this way?
Binary compatibility is not represented in pg_type (which is a shortcoming).
You have to use the IsBinaryCompatible()
On Thu, 2002-04-04 at 14:17, Oleg Bartunov wrote:
Subject: Bidirectional hard joins
>
> Hi,
>
>
> Here we propose some essential improvement of postgreSQL functionality,
> which may provide a great perfomance increase.
>
> 1. Problem
>
> The fastest way to find and fetch a record from a ta
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think we have only a few options:
You forgot
o Do nothing.
IMHO the current behavior is not broken, and does not need fixed.
All of the options you suggest are surely more broken than the current
behavior.
> o Issue a RESET on trans
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> PUBLIC can be made less reserved easily. See patch below.
Well, we could do that, but this patch seems an ugly way to do it;
we have too many classifications of keywords already, and I don't
want to introduce another one.
I'd be inclined to make PU
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> I see. However my main problem is that the schema of unqualified
> vs1 is affected by the existence of yamada.vs1. I don't think
> it's a useful behavior.
Well, if you don't like it, you could set the search_path to be just
public, or public and then th
On Wed, 2002-04-03 at 06:52, Gavin Sherry wrote:
> On Wed, 3 Apr 2002, Christopher Kings-Lynne wrote:
>
> > Hi,
> >
> > Would it be an idea to have pg_dump append an ANALYZE; command to the end of
> > its dumps to assist newbies / inexperienced admins?
>
> I do not think this is desired behavio
I am full agreement with proposal. I love it!!
(1) const or constant
(2) cacheable
(3) volatile
P.S.
Tom: My mail doesn't reach you. As an AT&T user, you block my machine's IP
address with the anti-spam blocking. :-(
Tom Lane wrote:
>
> Since I'm about to have to edit pg_proc.h to add a namesp
mlw <[EMAIL PROTECTED]> writes:
> quicksort is a pretty poor algorithm if your data is in some kind of order
> already.
Only if you fail to take standard precautions against making a bad
choice of pivot element; every discussion I've ever seen of quicksort
explains ways to avoid that pitfall. So
OK, I have a few ideas on this and I think one of them will have to be
implemented. Basically, we have this SET problem with all our
variables, e.g. if you SET explain_pretty_print or enable_seqscan in a
multi-statement transaction, and the transaction aborts after the
variable is turned on but
Tom,
I attached a message from my colleague and think it'd be interesting
to you. A short history: During developing of one project on
Windows platform, Teodor has discovered a pretty nice feature of Gigabase
(free embedded database by Konstantin Knizhnik,
http://www.geocities.com/kknizhnik/gigab
On Thu, 4 Apr 2002, Bruce Momjian wrote:
> Gilles DAROLD wrote:
> > Hi Justin,
> >
> > I have a new updated version of the Ora2Pg tool which correct many
> > problems and add some new features, could you or someone else update
> > the contrib directory.
> > (download at: http://www.samse.fr/GPL/o
43 matches
Mail list logo
