On Wed, Apr 23, 2008 at 4:20 AM, Merlin Moncure [EMAIL PROTECTED] wrote:
On Tue, Apr 22, 2008 at 4:10 PM, Gurjeet Singh [EMAIL PROTECTED]
wrote:
RECORD.* doesn't work in plpgsql, but NEW.* and OLD.* do in trigger
functions created in plpgsql.
The example function process_emp_audit()
Hi,
we have a customer who shot themselves in the foot by using
table names with german accented characters in them.
The client application on the popular OS is using a single-byte
encoding (LATIN9), their dump of the original database is using
the same but no SET client_encoding = ... line
On Wed, Apr 23, 2008 at 10:02:37AM +0200, Zoltan Boszormenyi wrote:
But the question popped up whether PostgreSQL can be extended
to allow localized literals and apply encoding conversion the same
way as on string data. NAMEDATA can be replaced with regular TEXT
and have the same conversion
James Mansion wrote:
Magnus Hagander wrote:
You interested in trying to code up a patch to verify that? ;)
Practical reality says that I won't get to this before the next
version of Windows is released.
I don't want to promise something I can't deliver.
:-)
If you want to throw me
Martijn van Oosterhout írta:
On Wed, Apr 23, 2008 at 10:02:37AM +0200, Zoltan Boszormenyi wrote:
But the question popped up whether PostgreSQL can be extended
to allow localized literals and apply encoding conversion the same
way as on string data. NAMEDATA can be replaced with regular TEXT
Example : let's imagine a cache priority setting.
Which we can presume the DBA will set incorrectly because the tools
needed to set that right aren't easy to use.
LOL, yes.
Jim threw out that you can just look at the page hit percentages
instead. That's not completely true. If
The optimizer could then use a different (much lower) value of
random_page_cost for tables for which cache priority is set
highest since it would know.
cache priority to me sounds like we're trying to influence caching
behavior, which isn't what's happening. I do agree that we
* If there is not a version mismatch, psql tells you nothing but
ask for help if you need it.
That was NOT part of the agreement. The version line should stay.
Why do we care, if the version matches? Not that I am feeling like
fighting about it but it seems just a waste of
Can anybody recall a reason for why the do_restart() function in pg_ctl
copies a lot of code almost right off from do_stop(), instead of just
having that code exactly the same as do_stop() and factored out? (Like
it does for do_start() already)
I see the point in dealing with the very first
On Tue, 2008-04-08 at 17:10 -0400, Tom Lane wrote:
What seems possibly more useful is to reintroduce \cwait (or hopefully
some better name) and give it the semantics of wait for a response from
any active connection; switch to the first one to respond, printing its
name, and print its result.
Magnus Hagander [EMAIL PROTECTED] writes:
Can anybody recall a reason for why the do_restart() function in pg_ctl
copies a lot of code almost right off from do_stop(), instead of just
having that code exactly the same as do_stop() and factored out? (Like
it does for do_start() already)
I see
On Wed, 2008-04-09 at 20:30 -0400, Tom Lane wrote:
* GIT (Grouped Index Tuple) indexes, which achieve index space savings
in btrees by having a single index tuple represent multiple heap tuples
(on a single heap page) containing a range of key values. I am not sure
what the development
Simon Riggs [EMAIL PROTECTED] writes:
I don't see the returns index keys idea as being killed by or killing
this concept. Returning keys is valid and useful when we can, but there
are other considerations that, in some use cases, will be a dominant
factor.
The patch as-submitted was a killer
Hello,
O.k. here is version 3 of the patch.
It is the same patch except that on standard connect it emits the
client version. It does not emit the server version unless their is a
mismatch. Does that make sense?
Sincerely,
Joshua D. Drake
--
The PostgreSQL Company since 1997:
On Wed, 23 Apr 2008 09:24:42 -0700
Joshua D. Drake [EMAIL PROTECTED] wrote:
Hello,
O.k. here is version 3 of the patch.
It is the same patch except that on standard connect it emits the
client version. It does not emit the server version unless their is a
mismatch. Does that make sense?
Joshua D. Drake wrote:
O.k. here is version 3 of the patch.
It is the same patch except that on standard connect it emits the
client version. It does not emit the server version unless their is a
mismatch. Does that make sense?
But you didn't fix any of the whitespace issues I mentioned
On Wed, 23 Apr 2008 12:38:22 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
Joshua D. Drake wrote:
O.k. here is version 3 of the patch.
It is the same patch except that on standard connect it emits the
client version. It does not emit the server version unless their is
a mismatch.
On Wed, 2008-04-23 at 12:07 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I don't see the returns index keys idea as being killed by or killing
this concept. Returning keys is valid and useful when we can, but there
are other considerations that, in some use cases, will be a
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
WARNING: Server version 8.2, psql version 8.4.
psql features may not work.
Can we say Some psql features...? the lowercase looks odd.
I left off server version because there doesn't seem to be a
reason to have it except if the server
On Wed, 23 Apr 2008 17:28:04 -
Greg Sabino Mullane [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
WARNING: Server version 8.2, psql version 8.4.
psql features may not work.
Can we say Some psql features...? the lowercase looks odd.
Yep. I struggled
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2008-04-23 at 12:07 -0400, Tom Lane wrote:
To be acceptable, a GIT patch would have to be optional and it
would have to expose in the catalogs whether a given index was lossy
in this way or not (so that the planner could know whether a plan based
On Wed, 2008-04-23 at 14:06 -0400, Tom Lane wrote:
I think storage parameter is no good also, given the current design that
assumes those can be changed on-the-fly. It'd be okay to GIT-ify an
existing index, perhaps, but not the other way round.
I was considering a new pg_index column. Or
I wrote:
After further thought about this, and about the new ForceToNull
expression node that I was suggesting, I have a more radical proposal
in mind: let's get rid of join alias variables, instead of expanding
their use.
I've been studying this idea more, and it seems workable and useful,
On Wed, 23 Apr 2008 10:48:24 -0700
Joshua D. Drake [EMAIL PROTECTED] wrote:
O.k. I *think* this should do it.
Added word Some
Version shows up no matter what
Server version shows up only if:
major or minor version doesn't match (same same as previous behavior)
Joshua D. Drake
--
The
Joshua D. Drake wrote:
On Wed, 23 Apr 2008 10:48:24 -0700
Joshua D. Drake [EMAIL PROTECTED] wrote:
O.k. I *think* this should do it.
Whitespace still broken
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom
On Wed, 23 Apr 2008 17:22:10 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
Joshua D. Drake wrote:
On Wed, 23 Apr 2008 10:48:24 -0700
Joshua D. Drake [EMAIL PROTECTED] wrote:
O.k. I *think* this should do it.
Whitespace still broken
Well maybe if we just declared that English is
Joshua D. Drake wrote:
! puts(_(\n));
! puts(_(You are using psql, the command-line interface
to PostgreSQL.\n));
! puts(_(\tFor SQL help type \\h or \\help .));
^
On Wed, 23 Apr 2008 17:44:43 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
Joshua D. Drake wrote:
! puts(_(\n));
! puts(_(You are using psql, the
command-line interface to PostgreSQL.\n)); !
puts(_(\tFor SQL help type \\h or
Joshua D. Drake wrote:
On Wed, 23 Apr 2008 17:44:43 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
Joshua D. Drake wrote:
Ahh o.k. Now I have a complaint. :) I happily removed the whitespace
where I saw this, %s \n (for example) but the whitespace above is for
readability. Consider:
On Wed, 23 Apr 2008 17:54:45 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
Right. I suggest you open the file in meld which allows you to
easily remove the offending extraneous difference. Of course, you
can do it in Vim or Emacs directly, but I don't think Joe can do
anything of the sort
I have moved this discussion to hackers in hopes of getting more
feedback, and moved the patch to a static URL:
ftp://momjian.us/pub/postgresql/mypatches/wrap
This patch adds a new '\pset format wrapped' mode that wraps long values
to fit the table on the user's screen, or in '\pset
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 24, 2008 at 8:30 AM, Bruce Momjian
wrote:
I have moved this discussion to hackers in hopes of getting more
feedback, and moved the patch to a static URL:
Hi Bruce,
This is a very cool feature! Looking through the patch I did have a
Brendan Jurd wrote:
This is a very cool feature! Looking through the patch I did have a
few thoughts.
This is definitely going to introduce merge conflicts with my
printTable API patch. That's not a problem, just a note to self
that when/if this patch goes in I'll have to submit a fresh
Joshua D. Drake wrote:
On Wed, 23 Apr 2008 09:24:42 -0700
Joshua D. Drake [EMAIL PROTECTED] wrote:
Hello,
O.k. here is version 3 of the patch.
It is the same patch except that on standard connect it emits the
client version. It does not emit the server version unless their is a
Simon Riggs wrote:
GIT significantly reduces the size of clustered indexes, greatly
improving the number of index pointers that can be held in memory for
very large indexes. That translates directly into a reduction in I/O for
large databases on typical hardware, for primary operations, file
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2008-04-23 at 12:07 -0400, Tom Lane wrote:
To be acceptable, a GIT patch would have to be optional and it
...
I was considering a new pg_index column. Or else we'd have to fix
the storage-parameter infrastructure to support
Bruce Momjian [EMAIL PROTECTED] writes:
Brendan Jurd wrote:
To me, this message sounds like you're setting the width of a single
column, when in fact you're setting the target *total* width of the
table. I think this message would be more clear if it read Target
output width ... or Target
Decibel! wrote:
we can just look at
the hit rate for the object. But we'd also need stats for how often we
find pages for a relation in the OS cache, which no one has come up with
a good method for.
Makes me wonder if we could (optionally, I guess, since timing
stuff is apparently slow on
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Brendan Jurd wrote:
To me, this message sounds like you're setting the width of a single
column, when in fact you're setting the target *total* width of the
table. I think this message would be more clear if it read Target
39 matches
Mail list logo
