On 1/15/07, Peter Eisentraut [EMAIL PROTECTED] wrote:
Client encoding is A, server encoding is B. Client sends an xml datum
that looks like this:
INSERT INTO table VALUES (xmlparse(document '?xml version=1.0
encoding=C?content.../content'));
Assuming that A, B, and C are all distinct, this
Am Montag, 15. Januar 2007 12:42 schrieb Nikolay Samokhvalov:
On 1/15/07, Peter Eisentraut [EMAIL PROTECTED] wrote:
Client encoding is A, server encoding is B. Client sends an xml datum
that looks like this:
INSERT INTO table VALUES (xmlparse(document '?xml version=1.0
Tom Lane wrote:
The DROP is at risk, but CREATE is also at risk because autovac feels
free to connect to template0. (One of the reasons we invented template0
was to prevent CREATE DATABASE failures due to someone-else-connected,
but autovac has broken that idea.)
ALTER DATABASE RENAME also
Neil Conway wrote:
On Thu, 2007-01-11 at 14:36 -0500, Neil Conway wrote:
I don't think they need to be integrated any time soon, but if we were
to design pg_dump and pg_dumpall from scratch, it seems more logical to
use a single program
On thinking about this some more, it might be
On Dec 19, 2006, at 12:06 PM, Carlo Stonebanks wrote:
I would like to create an ODBC DSN for a user to export files rom
Acccess to
a safe area. Right now, all tables are being dumped to public by
default.
In order to use the one-click export option for Access, I would
like to have
the
Hi Jim,
The solution was to put set search_path=new_path in Connection Settings
in the ODBC configuration (on Page 2 of the dialog).
Carlo
-Original Message-
From: Jim Nasby [mailto:[EMAIL PROTECTED]
Sent: January 14, 2007 10:07 PM
To: Carlo Stonebanks
Cc: [EMAIL PROTECTED]; PGSQL
Alvaro Herrera [EMAIL PROTECTED] writes:
I'm cooking a patch for this which seems pretty reasonable, but I'm
having a problem: what mechanism do we have for waiting until a process
exits?
None, and I think you probably don't want to sit on the database lock
while waiting, either. I was
So I've been working on the scheme I suggested a few days ago of
representing equivalence classes of variables explicitly, and avoiding
the current ad-hocery of generating and then removing redundant clauses
in favor of generating only the ones we want in the first place. Any
clause that looks
Peter Eisentraut wrote:
Am Montag, 15. Januar 2007 12:42 schrieb Nikolay Samokhvalov:
On 1/15/07, Peter Eisentraut [EMAIL PROTECTED] wrote:
Client encoding is A, server encoding is B. Client sends an xml datum
that looks like this:
INSERT INTO table VALUES (xmlparse(document '?xml
Simon Riggs wrote:
On Fri, 2006-12-29 at 20:25 -0300, Alvaro Herrera wrote:
Christopher Browne wrote:
Seems to me that you could get ~80% of the way by having the simplest
2 queue implementation, where tables with size some threshold get
thrown at the little table queue, and tables above
Pavan Deolasee wrote:
Simon Riggs wrote:
On Fri, 2006-12-29 at 20:25 -0300, Alvaro Herrera wrote:
Christopher Browne wrote:
Seems to me that you could get ~80% of the way by having the simplest
2 queue implementation, where tables with size some threshold get
thrown at the little table
Am Montag, 15. Januar 2007 17:33 schrieb Florian G. Pflug:
Would this mean that if the client_encoding is for example latin1, and I
retrieve an xml document uploaded by a client with client_encoding utf-8
(and thus having encoding=c in the xml tag), that I would get a
document with latin1
Tom Lane wrote:
Instead, I'm thinking it might be time to re-introduce some notion of
function execution cost into the system, and make use of that info to
sort WHERE clauses into a reasonable execution order.
That sounds like a straightforward idea.
This example
would be fixed with even a
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Would a simple constant value be workable, or do we need some more
complex model (and if so what)?
A simple constant would probably be enough. If we want anything fancier
than that, it should be up to the author of the function to
On Mon, Jan 15, 2007 at 05:47:37PM +0100, Peter Eisentraut wrote:
Am Montag, 15. Januar 2007 17:33 schrieb Florian G. Pflug:
Would this mean that if the client_encoding is for example latin1, and I
retrieve an xml document uploaded by a client with client_encoding utf-8
(and thus having
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
A simple constant would probably be enough. If we want anything fancier
than that, it should be up to the author of the function to define the
cost model as well. I'm envisioning that you could attach a custom cost
function to a
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
If we go this route it seems like we'll need four more columns in
pg_proc (cost estimation function OID, rowcount estimation function OID,
fallback cost constant, fallback rowcount constant).
What would the fallbacks be for?
By
Peter Eisentraut wrote:
Am Montag, 15. Januar 2007 17:33 schrieb Florian G. Pflug:
Would this mean that if the client_encoding is for example latin1, and I
retrieve an xml document uploaded by a client with client_encoding utf-8
(and thus having encoding=c in the xml tag), that I would get a
Tom Lane wrote:
Also see Peter's nearby suggestion that we ought to wait instead of fail
for *all* cases of somebody attached to the database. This would adapt
readily enough to that.
I was complaining elsewhere that I didn't want to use a sleep loop
for fixing the fsync-synchronization
Alvaro Herrera [EMAIL PROTECTED] writes:
Note that currently there's no way for a backend to know whether another
backend is autovacuum or not. I thought about adding a flag to PGPROC,
but eventually considered it ugly,
No, that was exactly the way I thought we'd do it. One thing to note is
On Mon, 15 Jan 2007, Tom Lane wrote:
So I've been working on the scheme I suggested a few days ago of
representing equivalence classes of variables explicitly, and avoiding
the current ad-hocery of generating and then removing redundant clauses
in favor of generating only the ones we want in
On Mon, 2007-01-15 at 10:51 -0800, Richard Troy wrote:
I therefore propose that the engine evaluate -
benchmark, if you will - all functions as they are ingested, or
vacuum-like at some later date (when valid data for testing may exist),
and assign a cost relative to what it already knows -
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
pg_control is certainly not ever deleted or renamed, and in fact I
believe there's an LWLock enforcing that only one PG process at a time
is even touching it. So we need another theory to explain this one :-(
Right.
Magnus Hagander [EMAIL PROTECTED] writes:
But yeah, that's probably a good idea. A quick look at the code says we
should at least ask people who have this problem to give it a run with
logging at DEBUG5 which should then log exactly what the errorcode was.
Or are you seeing more places that
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
But yeah, that's probably a good idea. A quick look at the code says we
should at least ask people who have this problem to give it a run with
logging at DEBUG5 which should then log exactly what the errorcode was.
Or are you seeing
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
DEBUG5 is going to be a bit voluminous, but let's try that if we can.
Perhaps we should switch down the DEBUG level of it, at least until we
know what happens?
That would have to wait on another update release, or at least someone
On Mon, 15 Jan 2007, Neil Conway wrote:
On Mon, 2007-01-15 at 10:51 -0800, Richard Troy wrote:
I therefore propose that the engine evaluate -
benchmark, if you will - all functions as they are ingested, or
vacuum-like at some later date (when valid data for testing may exist),
and assign
Neil Conway wrote:
On Mon, 2007-01-15 at 10:51 -0800, Richard Troy wrote:
I therefore propose that the engine evaluate -
benchmark, if you will - all functions as they are ingested, or
vacuum-like at some later date (when valid data for testing may exist),
and assign a cost relative to what
Brian Hurt [EMAIL PROTECTED] writes:
Non-developer here, but we use a lot of plpgsql functions at work. And
the functions we use fall into two broad, ill-defined catagories-
expensive functions and cheap functions. What I'd like as a user is
some way to tell the planner this function is
On Mon, 2007-01-15 at 15:05 -0500, Tom Lane wrote:
maybe we should just do the constant for starters and see how many
people really want to write C-code estimators ...
+1
BTW, your proposal would still pushdown all qualifiers, right?
Hellerstein's xfunc work discusses situations in which it
Martijn van Oosterhout wrote:
The only real alternative is to treat xml more like bytea than text
(ie, treat the input as a stream of octets).
bytea isn't treated any different than other data types. You just
have to take care in the client that you escape every byte greater than
127. The
Florian G. Pflug wrote:
Couldn't the server change the encoding declaration inside the xml to
the correct
one (the same as client_encoding) before returning the result?
The data type output function doesn't know what the client encoding is
or whether the data will be shipped to the client at
Neil Conway [EMAIL PROTECTED] writes:
BTW, your proposal would still pushdown all qualifiers, right?
Yeah, I have no intention of readopting xfunc in the near future ...
especially seeing that it's possible for the user to force that
sort of thing if he really has to.
SELECT * FROM
On 1/12/07, Andrew Dunstan [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
What do you think about setting up the buildfarm clients
with the users they are willing to test patches for, as opposed to
having the patch system track who is are trusted users? My thoughts
are the former is
Joachim Wieland wrote:
On Thu, Jan 11, 2007 at 09:59:14PM +0100, Magnus Hagander wrote:
.. appears to have killed win32. It did kill my manual MSVC builds, but
it also seems to have killed win32 buildfarm members yak and snake:
Peter Eisentraut wrote:
Florian G. Pflug wrote:
Couldn't the server change the encoding declaration inside the xml to
the correct
one (the same as client_encoding) before returning the result?
The data type output function doesn't know what the client encoding is
or whether the data will be
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Here it is.
I'd drop the InitProcess API change, which touches many more places than
you really need, and just have InitProcess check IsAutoVacuumProcess(),
which should be valid by the time control gets to it. This is more like
Florian G. Pflug wrote:
Sorry, I don't get it - how does this work for text, then? It works
there to dynamically recode the data from the database encoding to
the client encoding before sending it off to the client, no?
Sure, but it doesn't change the text inside the datum.
--
Peter
Peter Eisentraut wrote:
Florian G. Pflug wrote:
Couldn't the server change the encoding declaration inside the xml to
the correct
one (the same as client_encoding) before returning the result?
The data type output function doesn't know what the client encoding is
or whether the data will be
Andrew Dunstan wrote:
We should error out on any explicit encoding that conflicts with the
client encoding. I don't like the idea of just ignoring an explicit
encoding decl.
That is an instance of the problem of figuring out which encoding names
are equivalent, which I believe we have settled
On Sunday 14 January 2007 08:45, Joshua D. Drake wrote:
While we are talking autovacuum improvements, I'd like to also see some
better logging, something that is akin to the important information of
vacuum verbose being logged to a table or baring that the error_log. I'd
like to be able
Darcy Buskermolen wrote:
On Sunday 14 January 2007 08:45, Joshua D. Drake wrote:
While we are talking autovacuum improvements, I'd like to also see some
better logging, something that is akin to the important information of
vacuum verbose being logged to a table or baring that the error_log.
I wrote:
We need to decide on how to handle encoding information embedded in
xml data that is passed through the client/server encoding
conversion.
Tangentially related, I'm currently experimenting with a setup that
stores all xml data in UTF-8 on the server, converting it back to the
server
On Monday 15 January 2007 15:23, Joshua D. Drake wrote:
Darcy Buskermolen wrote:
On Sunday 14 January 2007 08:45, Joshua D. Drake wrote:
While we are talking autovacuum improvements, I'd like to also see some
better logging, something that is akin to the important information of
vacuum
I'm becoming confused by the encoding conversion API, in particular by
the function
pg_do_encoding_conversion(unsigned char *src, int len, int src_encoding,
int dest_encoding);
Since the function in various circumstances passes back src directly,
you might get back a string that encompasses
From: Magnus Hagander [EMAIL PROTECTED]
But yeah, that's probably a good idea. A quick look at the code says
we
should at least ask people who have this problem to give it a run
with
logging at DEBUG5 which should then log exactly what the errorcode
was.
Or are you seeing more places that need
Peter Eisentraut [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
Are we going to ensure that what we hand back to another client has
an appropriate encding decl? Or will we just remove it in all cases?
We can't do the former, but the latter might be doable.
I think that in the case of binary
Takayuki Tsunakawa [EMAIL PROTECTED] writes:
BTW, why does the bgwriter try to open and write the pages of already
dropped relations?
It does not; the problem is with stale fsync requests.
If the relation being dropeed has
already been registered in the list of files to be fsynced, isn't it
48 matches
Mail list logo
