On Thursday 28 May 2009 00:54:32 Tom Lane wrote:
To wit, the current
coding fails to respect the gettext domain when working with pluralized
messages.
The ngettext() calls use the default textdomain that main.c sets up. The PLs
use dngettext(). Is that not correct?
--
Sent via
On Wednesday 27 May 2009 23:02:19 Zdenek Kotala wrote:
Peter Eisentraut píše v út 26. 05. 2009 v 13:39 +0300:
Of course the concrete example that you show doesn't actually take
advantage of this, so if it is important to you, please send a patch to
fix it.
Fix attached. I found only two
On Wed, 2009-05-27 at 21:09 -0400, Tom Lane wrote:
So, if we assume that these numbers are real and not artifacts, it seems
we have to postulate at least four distinct block-size-dependent
performance effects:
Two performance effects would be sufficient to explain the results.
* Optimal
On Wed, 2009-05-27 at 17:51 -0700, Mark Wong wrote:
On Wed, May 27, 2009 at 1:46 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2009-05-26 at 19:51 -0700, Mark Wong wrote:
It appears for this workload using a 16KB or 32KB gets more than 4%
throughput improvement, but some of that
Hi,
Quoting Marc G. Fournier scra...@hub.org:
Please repost ...
Peter referred to this message here:
http://archives.postgresql.org/pgsql-hackers/2008-12/msg01879.php
However, please be cautious before applying such a patch.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list
Hi,
Quoting Marc G. Fournier scra...@hub.org:
Actually, I have done that on at least one of the 8.x tags too, so
if that is it, more then those two tags should be causing issues ...
Not *every* such issue causes problems. An example that's perfectly fine:
cvs commit -m first commit fileA
Hi,
Quoting Robert Haas robertmh...@gmail.com:
I think this is a semantic argument. The problem isn't that we don't
understand how CVS behaves; it's that we find that behavior
undesirable
I fully agree to that and find it undesirable as well.
aka broken.
Well, for some it's a feature,
Hi all,
Seems the night has been providing lots of thoughs :)
Josh Berkus j...@agliodbs.com writes:
Sure. I think that having better search path management would be a
wonderful thing; it would encourage people to use schema more in general.
However, that doesn't mean that I think it should
Robert Haas robertmh...@gmail.com writes:
The contents of a particular schema are more or less analagous to an
application. In most programming languages, an application informs
the system of the libraries that it needs and the system goes off and
loads the symbols in those libraries into the
Andrew Dunstan and...@dunslane.net writes:
Dimitri Fontaine wrote:
we all agree that a specific pg_extension schema is a good idea, as
soon as user is free not to use it at extension install time.
I don't think we all agree on that at all. ;-)
Ooops, my mistake, as few people where
Hi,
Tom Lane t...@sss.pgh.pa.us writes:
Andrew Gierth and...@tao11.riddles.org.uk writes:
Splitting up search_path is something I've been thinking about for a
while (and threw out on IRC as a suggestion, which is where Dimitri
got it); it was based on actual experience running an app that set
I attached another cleanup patch which fixes following warnings reported
by Sun Studio:
zic.c, line 1534: warning: const object should have initializer: tzh0
dynloader.c, line 7: warning: empty translation unit
pgstat.c, line 666: warning: const object should have initializer: all_zeroes
Kevin Grittner wrote:
1. implementation of the paper's technique sans predicate locking,
that would avoid more serialization anomalies but not all?
I saw that as a step along the way to support for fully serializable
transactions. If covered by a migration path GUC which defaulted to
Tom Lane t...@sss.pgh.pa.us wrote:
=# SELECT xmlelement(name a, xmlattributes('./qa?a=1b=2' as href), 'QA');
xmlelement
a href=./qa?a=1amp;amp;b=2Qamp;A/a
'' in xmlattributes seems to be encoded twice.
This was
Guillaume Smet wrote:
On Tue, Apr 28, 2009 at 5:35 PM, Guillaume Smet
guillaume.s...@gmail.com wrote:
On Tue, Apr 28, 2009 at 5:22 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
At a normal startup, the checkpoint record would be there as usual. And an
archive recovery
On Thu, May 28, 2009 at 11:11:20AM +0200, Zdenek Kotala wrote:
I attached another cleanup patch which fixes following warnings reported
by Sun Studio:
...
preproc.c, line 39569: warning: pointer expression or its operand do not
point to the same object yyerror_range, result is undefined and
Michael Meskes píše v čt 28. 05. 2009 v 13:33 +0200:
On Thu, May 28, 2009 at 11:11:20AM +0200, Zdenek Kotala wrote:
I attached another cleanup patch which fixes following warnings reported
by Sun Studio:
...
preproc.c, line 39569: warning: pointer expression or its operand do not
On Thursday 28 May 2009 04:49:19 Tom Lane wrote:
Yeah. The fundamental problem with all the practical approaches I've
heard of is that they only work for a subset of possible predicates
(possible WHERE clauses). The idea that you get true serializability
only if your queries are phrased just
* Dimitri Fontaine (dfonta...@hi-media.com) wrote:
Andrew Dunstan and...@dunslane.net writes:
Dimitri Fontaine wrote:
we all agree that a specific pg_extension schema is a good idea, as
soon as user is free not to use it at extension install time.
I don't think we all agree on that
Peter Eisentraut wrote:
On Thursday 28 May 2009 04:49:19 Tom Lane wrote:
Yeah. The fundamental problem with all the practical approaches I've
heard of is that they only work for a subset of possible predicates
(possible WHERE clauses). The idea that you get true serializability
only if your
* Dimitri Fontaine (dfonta...@hi-media.com) wrote:
A better way to solve this is to have the database post_search_path (or
call it search_path_suffix) contain the extensions schemas. Now the
roles are set up without search_path_suffix, and it's easy to add an
extension living in its own
On Thursday 28 May 2009 03:38:49 Tom Lane wrote:
* SET TRANSACTION ISOLATION LEVEL something-else should provide our
current snapshot-driven behavior. I don't have a strong feeling about
whether something-else should be spelled REPEATABLE READ or SNAPSHOT,
but lean slightly to the latter.
On Thursday 28 May 2009 15:24:59 Heikki Linnakangas wrote:
I don't think you need that for predicate locking. To determine if e.g
an INSERT and a SELECT conflict, you need to determine if the INSERTed
tuple matches the predicate in the SELECT. No need to deduce anything
between two predicates,
On Thu, May 28, 2009 at 01:51:07PM +0200, Zdenek Kotala wrote:
Problem is with YYLLOC_DEFAULT. When I look on macro definition
#define YYLLOC_DEFAULT(Current, Rhs, N) \
Current.first_line = Rhs[1].first_line; \
Current.first_column = Rhs[1].first_column;\
* Robert Haas robertmh...@gmail.com [090527 22:43]:
On Wed, May 27, 2009 at 10:09 PM, Aidan Van Dyk ai...@highrise.ca wrote:
* Robert Haas robertmh...@gmail.com [090527 21:30]:
And actually looking at the history of the gpo repo, the branches are all
messed up with merges and stuff that
On Thu, 2009-05-28 at 14:04 +0300, Heikki Linnakangas wrote:
I've committed a patch to do the RequstXLogSwitch() before shutdown
checkpoint as discussed. It seems safe to me. (sorry for the delay, and
thanks for the reminder)
Not sure if that is a fix that will work in all cases.
There
Simon Riggs wrote:
On Thu, 2009-05-28 at 14:04 +0300, Heikki Linnakangas wrote:
I've committed a patch to do the RequstXLogSwitch() before shutdown
checkpoint as discussed. It seems safe to me. (sorry for the delay, and
thanks for the reminder)
Not sure if that is a fix that will work in
On Thu, 2009-05-28 at 16:19 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Thu, 2009-05-28 at 14:04 +0300, Heikki Linnakangas wrote:
I've committed a patch to do the RequstXLogSwitch() before shutdown
checkpoint as discussed. It seems safe to me. (sorry for the delay, and
On Wed, 2009-05-27 at 12:08 -0400, Bruce Momjian wrote:
Ideally someone would have
taken ownership of the issue, summarized the email conclusions, gotten
a patch together, and submitted it for application.
Just a further comment on this, based upon the patch Heikki recently
committed.
I
On Thu, May 28, 2009 at 8:59 AM, Aidan Van Dyk ai...@highrise.ca wrote:
All that based on the assumption that when the project switches to git,
they actually want all the CVS history in their official tree. Its
certainly not necessary, and possibly not even desirable... PostgreSQL
could just
Simon Riggs wrote:
On Thu, 2009-05-28 at 16:19 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Thu, 2009-05-28 at 14:04 +0300, Heikki Linnakangas wrote:
I've committed a patch to do the RequstXLogSwitch() before shutdown
checkpoint as discussed. It seems safe to me. (sorry for the
Greg Smith wrote:
On Wed, 27 May 2009, andy wrote:
I have a Sun blade 1000 that's just collecting dust now days...It
weighs a ton.
Bah, I know I picked one of those up myself once, which means it's far
from being what I'd consider a heavy server as Sun hardware goes. Specs
say it's 70
On Thu, 2009-05-28 at 16:52 +0300, Heikki Linnakangas wrote:
If the archiver is working, but has fallen behind at the point of
shutdown, does the archiver operate for long enough to ensure we are
archived up to the point of the log switch prior to checkpoint?
Yes, it archives all
Peter Eisentraut pete...@gmx.net writes:
On Thursday 28 May 2009 00:54:32 Tom Lane wrote:
To wit, the current
coding fails to respect the gettext domain when working with pluralized
messages.
The ngettext() calls use the default textdomain that main.c sets up. The PLs
use dngettext(). Is
* Robert Haas robertmh...@gmail.com [090528 09:49]:
On Thu, May 28, 2009 at 8:59 AM, Aidan Van Dyk ai...@highrise.ca wrote:
All that based on the assumption that when the project switches to git,
they actually want all the CVS history in their official tree. Its
certainly not necessary,
Robert Haas wrote:
On Thu, May 28, 2009 at 8:59 AM, Aidan Van Dyk ai...@highrise.ca wrote:
All that based on the assumption that when the project switches to git,
they actually want all the CVS history in their official tree. Its
certainly not necessary, and possibly not even desirable...
Simon Riggs wrote:
On Thu, 2009-05-28 at 16:52 +0300, Heikki Linnakangas wrote:
If the archiver is working, but has fallen behind at the point of
shutdown, does the archiver operate for long enough to ensure we are
archived up to the point of the log switch prior to checkpoint?
Yes, it
Michael Meskes píše v čt 28. 05. 2009 v 14:47 +0200:
On Thu, May 28, 2009 at 01:51:07PM +0200, Zdenek Kotala wrote:
Problem is with YYLLOC_DEFAULT. When I look on macro definition
#define YYLLOC_DEFAULT(Current, Rhs, N) \
Current.first_line = Rhs[1].first_line; \
On Thu, 2009-05-28 at 17:21 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
I don't think it does, please look again.
Still looks ok to me. pgarch_ArchiverCopyLoop() loops until all ready
WAL segments have been archived (assuming no errors).
No, it doesn't now, though it did used
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
1. Needs to be fully spec-compliant serializable behavior. No
anomalities.
That is what the paper describes, and where I want to end up.
2. No locking that's not absolutely necessary, regardless of the
WHERE-clause used. No
Albe Laurenz laurenz.a...@wien.gv.at wrote:
Every WHERE-clause in a SELECT will add one or more checks for each
concurrent writer.
That has not been the case in any implementation of predicate locks
I've used so far. It seems that any technique with those performance
characteristics would
Andrew Dunstan and...@dunslane.net writes:
Robert Haas wrote:
That would suck for me. I use git log a lot to see how things have
changed over time.
Indeed. Losing the history is not an acceptable option.
I think the same. If git is not able to maintain our project history
then it is not
On Thu, May 28, 2009 at 10:18 AM, Aidan Van Dyk ai...@highrise.ca wrote:
* Robert Haas robertmh...@gmail.com [090528 09:49]:
On Thu, May 28, 2009 at 8:59 AM, Aidan Van Dyk ai...@highrise.ca wrote:
All that based on the assumption that when the project switches to git,
they actually want all
Peter Eisentraut pete...@gmx.net wrote:
Could someone describe concisely what behavior snapshot isolation
provides that repeatable read does?
Phantom reads are not possible in snapshot isolation. They are
allowed to occur (though not required to occur) in repeatable read.
Note that in
On Thu, May 28, 2009 at 3:40 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
2. No locking that's not absolutely necessary, regardless of the
WHERE-clause used. No table locks, no page locks. Block only on
queries/updates that would truly conflict with concurrent updates
If you do a
Simon Riggs wrote:
On Thu, 2009-05-28 at 17:21 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
I don't think it does, please look again.
Still looks ok to me. pgarch_ArchiverCopyLoop() loops until all ready
WAL segments have been archived (assuming no errors).
No, it doesn't now, though
Simon Riggs wrote:
No, because as I said, if archive_command has been returning non-zero
then the archive will be incomplete.
Yes. You think that's wrong? How would you like it to behave, then? I
don't think you want the shutdown to wait indefinitely until all files
have been
On Thu, May 28, 2009 at 3:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
Robert Haas wrote:
That would suck for me. I use git log a lot to see how things have
changed over time.
Indeed. Losing the history is not an acceptable option.
I think the same.
On Thu, May 28, 2009 at 5:02 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
So you check. This solves Guillaume's immediate concern. If you have a
suggestion for further improvements, I'm all ears.
Thanks for applying the patch.
Yes, the problem is that before this change,
On 05/27/09 22:00, Josh Berkus wrote:
Andy,
I have a Sun blade 1000 that's just collecting dust now days. I was
wondering if there were any pg-hackers that could find use for it.
Its dual UltraSPARC III 750 (I think) and has two 36? gig fiber channel
scsi disks.
It weighs a ton.
I'd be
On Thu, 2009-05-28 at 17:16 +0200, Guillaume Smet wrote:
On Thu, May 28, 2009 at 5:02 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
So you check. This solves Guillaume's immediate concern. If you have a
suggestion for further improvements, I'm all ears.
Thanks for
Greg Stark st...@enterprisedb.com wrote:
Once again, the type of scan is not relevant. it's quite possible to
have a table scan and only read some of the records, or to have an
index scan and read all the records.
You need to store some representation of the qualifiers on the scan,
Hi,
Quoting Tom Lane t...@sss.pgh.pa.us:
I think the same. If git is not able to maintain our project history
then it is not mature enough to be considered as our official VCS.
As Aidan pointed out, the question is not *if* git can represent it.
It's rather *how*. Especially WRT changes of
On Thu, May 28, 2009 at 8:43 AM, Peter Eisentraut pete...@gmx.net wrote:
On Thursday 28 May 2009 15:24:59 Heikki Linnakangas wrote:
I don't think you need that for predicate locking. To determine if e.g
an INSERT and a SELECT conflict, you need to determine if the INSERTed
tuple matches the
Zdenek Kotala zdenek.kot...@sun.com writes:
I attached another cleanup patch which fixes following warnings reported
by Sun Studio:
I'm not too impressed with any of these. The proposed added
initializers just increase future maintenance effort without solving
any real problem (since the
On Thu, May 28, 2009 at 11:04 AM, Greg Stark st...@enterprisedb.com wrote:
On Thu, May 28, 2009 at 3:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
Robert Haas wrote:
That would suck for me. I use git log a lot to see how things have
changed over time.
On Thu, May 28, 2009 at 11:40 AM, Markus Wanner mar...@bluegap.ch wrote:
Quoting Tom Lane t...@sss.pgh.pa.us:
I think the same. If git is not able to maintain our project history
then it is not mature enough to be considered as our official VCS.
As Aidan pointed out, the question is not *if*
On Thu, May 28, 2009 at 5:36 PM, Simon Riggs si...@2ndquadrant.com wrote:
If you feel we have moved forwards, that's good, but since no part of
the *safe* maintenance procedure has changed, I don't see that myself.
Only the unsafe way of doing it got faster.
I disagree with you.
The situation
Hi,
Quoting Robert Haas robertmh...@gmail.com:
I don't think that was the idea - Aidan floated the idea of just
checking the current version of each branch into git, rather than
importing the full history from CVS (and letting indivdual cloners fix
their own history if they were so inclined).
On Thu, May 28, 2009 at 4:33 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Can you cite anywhere that such techniques have been successfully used
in a production environment
Well there's a reason our docs say: Such a locking system is complex
to implement and extremely expensive in
Michael Meskes mes...@postgresql.org writes:
I have to admit that those version look strikingly unsimilar to me. There is
no
reference to Rhs[N] in our macro at all. But then I have no idea whether this
is needed.
The default version of the macro is intended to track both the starting
and
Greg Stark st...@enterprisedb.com wrote:
I would want any serialization failure to be
justifiable by simple inspection of the two transactions.
BTW, there are often three (or more) transaction involved in creating
a serialization failure, where any two of them alone would not fail.
You
On Thu, 2009-05-28 at 17:50 +0200, Guillaume Smet wrote:
I think it's a step forward, maybe not sufficient for you but I prefer
the situation now than before. It's safer because of the principle of
least surprise: I'm pretty sure a lot of people didn't even think that
the last WAL file was
Hi,
Quoting Robert Haas robertmh...@gmail.com:
My understanding is that the histories of some of the branches we have
now are flat-out wrong.
AFAIU only the latest revisions of the branches have been compared.
Keeping history and future in mind, that's not telling much, IMO. In
my
Dmitry Koterov dmi...@koterov.ru writes:
No, I meant that in case of the row (1, NULL, NULL, 2, 3, NULL):
- the corresponding NULL bitmap is (100110...)
- the corresponding tuple is (1, 2, 3)
- t_natts=3 (if I am not wrong here)
You are wrong --- t_natts would be six here. In general
On Thu, May 28, 2009 at 6:06 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2009-05-28 at 17:50 +0200, Guillaume Smet wrote:
I think it's a step forward, maybe not sufficient for you but I prefer
the situation now than before. It's safer because of the principle of
least surprise: I'm
Robert Haas robertmh...@gmail.com writes:
What's hard about that? INSERTs are the hard case, because the rows
you care about don't exist yet. SELECT, UPDATE, and DELETE are easy
by comparison; you can lock the actual rows at issue. Unless I'm
confused?
UPDATE isn't really any easier than
Robert Haas robertmh...@gmail.com writes:
I'm still not sure who is going to take responsibility for fixing the
git tree we have now. I don't think it's going to work for us to
leave it broken until we're ready to do the cutover, and then do one
monolithic move. If the tools we're using to
On Thu, May 28, 2009 at 12:10 PM, Markus Wanner mar...@bluegap.ch wrote:
Hi,
Quoting Robert Haas robertmh...@gmail.com:
My understanding is that the histories of some of the branches we have
now are flat-out wrong.
AFAIU only the latest revisions of the branches have been compared. Keeping
On May 28, 2009, at 1:34 AM, Dimitri Fontaine wrote:
Andrew Dunstan and...@dunslane.net writes:
Dimitri Fontaine wrote:
we all agree that a specific pg_extension schema is a good idea,
as
soon as user is free not to use it at extension install time.
I don't think we all agree on that
On Thu, May 28, 2009 at 12:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I'm still not sure who is going to take responsibility for fixing the
git tree we have now. I don't think it's going to work for us to
leave it broken until we're ready to do the
Greg Stark st...@enterprisedb.com wrote:
On Thu, May 28, 2009 at 4:33 PM, Kevin Grittner wrote:
Can you cite anywhere that such techniques have been successfully
used in a production environment
Well there's a reason our docs say: Such a locking system is
complex to implement and extremely
On May 28, 2009, at 1:13 AM, Dimitri Fontaine wrote:
Having all extensions live in pg_extension schema also solves the
problem in a much easier way, except for people who care about not
messing it all within a single schema (fourre-tout is the french for a
place where you put anything and
Jignesh K. Shah wrote:
On 05/27/09 22:00, Josh Berkus wrote:
Andy,
I have a Sun blade 1000 that's just collecting dust now days. I was
wondering if there were any pg-hackers that could find use for it.
Its dual UltraSPARC III 750 (I think) and has two 36? gig fiber channel
scsi disks.
It
On Thu, 28 May 2009, Robert Haas wrote:
My understanding is that the histories of some of the branches we have
now are flat-out wrong. I don't have a problem keeping those
alongside the corrected history for ease of rebasing and porting
commits, but I don't want to punt the problem of figuring
Robert Haas robertmh...@gmail.com writes:
On Thu, May 28, 2009 at 12:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think
we will have to make a clean cutover from CVS is authoritative to
CVS is dead and git is authoritative, and do a fresh repository
conversion at that instant. What we should
Greg Smith wrote:
On Thu, 28 May 2009, Andy Colson wrote:
Yeah, when it shipped I think it was about 75 pounds. It is a tower,
yes, and an impressively large box (my experience with servers is
limited, this is the first I've ever gotten to play with, so it may
not be out of the ordinary).
On Thu, 2009-05-28 at 18:02 +0300, Heikki Linnakangas wrote:
postmaster never sends SIGTERM to pgarch, and postmaster is still alive.
Then we have a regression, since we changed the code to make sure the
archiver did shutdown even if there was a backlog. The reason is that if
there is a long
Robert Haas escribió:
To me they sound complex and inconvenient. I guess I'm kind of
mystified by why we can't make this work reliably. Other than the
broken tags issue we've discussed, it seems like the only real issue
should be how to group changes to different files into a single
Greg Smith gsm...@gregsmith.com writes:
The best way to control the scope creep here is to avoid doing that, and
instead focus on what you really need from the repo conversion. [...]
If the goalposts are moved to every ancient tag/release ever must build
perfectly and have sane history no
Alvaro Herrera alvhe...@commandprompt.com writes:
There's another issue which is that of the $Id$ and similar tags. We
have to decide what we want to do with them. If we're not going to have
them in the Git repository, then they are only causing trouble right now
and it would be better to
On Thu, May 28, 2009 at 12:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
What's hard about that? INSERTs are the hard case, because the rows
you care about don't exist yet. SELECT, UPDATE, and DELETE are easy
by comparison; you can lock the actual rows
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Right. Shall we try to spec out exactly what our conversion
requirements are? Here's a shot:
[...]
Comments? Other considerations?
Certainly sounds reasonable to me. I'd be really suprised if that's
really all that hard to accomplish. I'd be happy to
Simon Riggs wrote:
On Thu, 2009-05-28 at 18:02 +0300, Heikki Linnakangas wrote:
postmaster never sends SIGTERM to pgarch, and postmaster is still alive.
Then we have a regression, since we changed the code to make sure the
archiver did shutdown even if there was a backlog.
The commit
On Thu, May 28, 2009 at 12:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
There's another issue which is that of the $Id$ and similar tags. We
have to decide what we want to do with them. If we're not going to have
them in the Git repository, then
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com writes:
There's another issue which is that of the $Id$ and similar tags. We
have to decide what we want to do with them. If we're not going to have
them in the Git repository, then they are only causing trouble right now
and
Hello
current plpgsql cannot detect early some errors based on unknown
casting. Other problem is IO casting.
The reason is an late casting:
current_code is some like:
val = eval_expr(query, result_type);
if (result_type != expected_type)
{
str = convert_to_string(val, result_type);
val =
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
What was in the back of my mind was that we'd go around and mass-remove
$PostgreSQL$ (and any other lurking tags), but only from HEAD and only
after the repo conversion. Although just before it would be okay too.
You mean
Pavel Stehule pavel.steh...@gmail.com writes:
I propose for types with typmod -1 early casting - etc casting to
target type on planner level. We cannot use this method for defined
typmod, because we would to raise exception for following situation:
What existing coding habits will this break?
On Thu, May 28, 2009 at 5:30 PM, David E. Wheeler da...@kineticode.com wrote:
Yes, just as long as your extensions schema doesn't turn into a bricolage of
stuff. I mean, if I use a lot of extensions, it means that I end up with a
giant collection of functions and types and whatnot in this one
Dimitri Fontaine wrote:
we all agree that a specific pg_extension schema is a good idea, as
soon as user is free not to use it at extension install time.
I don't think we all agree on that at all. ;-)
cheers
andrew
--
Sent via pgsql-hackers mailing list
On 5/28/09 12:36 AM, Dimitri Fontaine wrote:
That really seems exactly to be what we're proposing with pre_ and post_
search_path components: don't change current meaning of search_path,
just give DBAs better ways to manage it. And now that you're leaning
towards a search_path suffix, don't you
Greg Stark st...@enterprisedb.com writes:
I don't understand what storing them in different namespaces and then
putting them all in your search_path accomplishes. You end up with the
same mishmash of things in your namespace.
+1 ... naming conflicts between different extensions are going to be
Josh Berkus j...@agliodbs.com writes:
On 5/28/09 12:36 AM, Dimitri Fontaine wrote:
That really seems exactly to be what we're proposing with pre_ and post_
search_path components: don't change current meaning of search_path,
just give DBAs better ways to manage it. And now that you're leaning
Andy,
Yeah, when it shipped I think it was about 75 pounds. It is a tower,
yes, and an impressively large box (my experience with servers is
limited, this is the first I've ever gotten to play with, so it may not
be out of the ordinary). I think my kill-a-watt said, at idle, it was
near 300W.
2009/5/28 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
I propose for types with typmod -1 early casting - etc casting to
target type on planner level. We cannot use this method for defined
typmod, because we would to raise exception for following situation:
What
Pavel Stehule pavel.steh...@gmail.com writes:
for typmod others then -1 we should to use IO cast - but we should to
check, if it's one from known casts.
I still think it's fundamentally wrong to be treating typmod -1 so
differently from other typmods. If this behavior is sane at all then
it
I use pgTAP to make sure my functions produce the correct errors using
throws_ok(). So when I get an error from a plpgsql function, it looks
like this:
ERROR: upper bound of FOR loop cannot be null
CONTEXT: PL/pgSQL function foo line 35 at FOR with integer loop
variable
...which I can then
On Thu, May 28, 2009 at 2:27 PM, Greg Stark st...@enterprisedb.com wrote:
On Thu, May 28, 2009 at 5:30 PM, David E. Wheeler da...@kineticode.com
wrote:
Yes, just as long as your extensions schema doesn't turn into a bricolage of
stuff. I mean, if I use a lot of extensions, it means that I end
On Thu, 28 May 2009, Tom Lane wrote:
Each released minor version tag must check out the same as from CVS, at
least back to some specified point (perhaps 7.4.0). I'd really prefer
to insist on that all the way back.
We'd all like to hope that conversion process that works for everything
1 - 100 of 169 matches
Mail list logo
