Hi,
> We already have system triggers -- the FK triggers. I don't think we've
>>> had all that much trouble with them.
>>>
>>>
>>
>> In the case of the FK triggers, it's intentional (and maybe even
>> documented) that users should be able to place their own triggers before
>> or after the FK trig
Is it possible to print which key value is duplicated when 'Duplicate
key value violates unique constraint' occurs? Foreign key violation
error reports such kind of information.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
"Andreas 'ads' Scherbaum" writes:
> although the "crypt" auth functionality is removed i 8.4 i found a
> remnant in the sample pg_hba.conf file. The attached patch removes the
> keyword from the config file.
Done, thanks.
regards, tom lane
--
Sent via pgsql-hackers mail
Robert Treat wrote:
> Actually I find the inconsistency to hurt usability, which is typically what
> you get with inconsistent interfaces.
>
> I'm not certain, but I think I would be happier if we did:
>
> \d*user space objects
> \d*S include system objects
>
> For those that want system
Hi,
I'm in a project that probably some of you have heart about, it is called
PostgreSQLf and I get some help before from this list. The developer team is
been doing some progress about. Now one of us has created an extra column
that is called membership degree, this performs some calculations ove
Hi,
On Fri, Mar 27, 2009 at 11:36 PM, Simon Riggs wrote:
>
> On Fri, 2009-03-27 at 10:25 -0400, Tom Lane wrote:
>> Peter Eisentraut writes:
>> > Simon Riggs wrote:
>> >> If we go with this, I would suggest we make *neither* the default by
>> >> removing -t, and adopting two new options: somethin
Hello,
although the "crypt" auth functionality is removed i 8.4 i found a
remnant in the sample pg_hba.conf file. The attached patch removes the
keyword from the config file.
Kind regards
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European Postgre
Robert Treat wrote:
> On Monday 30 March 2009 10:52:47 Bruce Momjian wrote:
> > Robert Haas wrote:
> > > On Mon, Mar 30, 2009 at 10:13 AM, Bruce Momjian wrote:
> > > > Maybe the best we are going to do is to have any pattern supplied to
> > > > \d* assume 'S' (include system objects). ?I actually
Peter Eisentraut writes:
> On Monday 30 March 2009 20:06:48 Heikki Linnakangas wrote:
>> LC_CTYPE. In 8.3 and up where we constrain that to match the database
>> encoding, we only have a problem with the C locale.
> Why don't we apply the same restriction to the C locale then?
(1) what would you
On Monday 30 March 2009 20:06:48 Heikki Linnakangas wrote:
> Tom Lane wrote:
> > Where does it get the default codeset from? Maybe we could constrain
> > that to match the database encoding, the way we do for LC_COLLATE/CTYPE?
>
> LC_CTYPE. In 8.3 and up where we constrain that to match the databa
On Monday 30 March 2009 21:04:00 Tom Lane wrote:
> Heikki Linnakangas writes:
> > Tom Lane wrote:
> >> Could we get away with just unconditionally calling
> >> bind_textdomain_codeset with *our* canonical spelling of the encoding
> >> name? If it works, great, and if it doesn't, you get English.
Alvaro Herrera writes:
> Tom Lane wrote:
>> At first that sounded like an ideal answer, but I can see a gotcha:
>> suppose the translation's author's name contains some characters that
>> don't convert to the database encoding. I suppose that would result in
>> failure, when we'd prefer it not to
On Saturday 28 March 2009 00:42:28 Bruce Momjian wrote:
> I assume directory permissions controlling access to the socket file
> would be enough. You are going to have to set up SSL certificates
> anyway for this so isn't that just as hard as telling the client where
> the socket file is located?
Tom Lane wrote:
> At first that sounded like an ideal answer, but I can see a gotcha:
> suppose the translation's author's name contains some characters that
> don't convert to the database encoding. I suppose that would result in
> failure, when we'd prefer it not to. A single-purpose string co
Hello
attached patch allows raising exception from _PG_init function as was
discussed before.
regards
Pavel Stehule
*** ./src/backend/utils/fmgr/dfmgr.c.orig 2009-03-31 20:32:21.0 +0200
--- ./src/backend/utils/fmgr/dfmgr.c 2009-03-31 21:59:36.0 +0200
***
*** 281,287 **
On Tue, 31 Mar 2009, Tom Lane wrote:
Oleg Bartunov writes:
How do you think is it right time to upgrade snowball stemmers ?
We didn't change them since 2007.
Probably you should ask the snowball people. I'm not sure if they have
a formal release cycle or not, but if they think their stuff
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Maybe use a special string "Translate Me First" that
>> doesn't actually need to be end-user-visible, just so no one sweats over
>> getting it right in context.
> Yep, something like that. There seems to be a magic empty string
> translation at the
Tom Lane wrote:
Heikki Linnakangas writes:
I'm leaning towards the idea of trying out all the spellings of the
database encoding we have in encoding_match_list. That gives the best
user experience, as it just works, and it doesn't seem that complicated.
How were you going to check --- use th
Abhijit Menon-Sen escreveu:
> That this family of functions did not exist earlier was merely an
> oversight.
>
Added to next commitfest. Thanks!
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
Oleg Bartunov writes:
> How do you think is it right time to upgrade snowball stemmers ?
> We didn't change them since 2007.
Probably you should ask the snowball people. I'm not sure if they have
a formal release cycle or not, but if they think their stuff is unstable
right now for some reason,
Hi there !
How do you think is it right time to upgrade snowball stemmers ?
We didn't change them since 2007.
Regards,
Oleg
_
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astr
Heikki Linnakangas writes:
> I'm leaning towards the idea of trying out all the spellings of the
> database encoding we have in encoding_match_list. That gives the best
> user experience, as it just works, and it doesn't seem that complicated.
How were you going to check --- use that idea of tr
I wrote:
> Alvaro Herrera writes:
>> (We already have rel->rd_istemp, but it's not what we need here.)
> Yeah. I was considering converting that into a three-state flag, but
> it might be simpler to remove it altogether and look to the new pg_class
> field; only after we've gone down the path in
Tom Lane píše v út 31. 03. 2009 v 13:10 -0400:
> Zdenek Kotala writes:
> > The main problem what I see here is that getopt and getopt_long works
> > together. Use one from system and one ported is not good idea.
>
> Well, the expected (and pretty-well-tested) case is that your system has
> geto
Heikki Linnakangas wrote:
One idea is to extract the encoding from LC_MESSAGES. Then call
pg_get_encoding_from_locale() on that and check that it matches
server_encoding. If it does, great, pass it to
bind_textdomain_codeset(). If it doesn't, throw an error.
I tried to implement this but it g
Alvaro Herrera escreveu:
> Euler Taveira de Oliveira wrote:
>> Tom Lane escreveu:
>>> Alvaro Herrera writes:
... However, on HEAD this is crashing for me, and it's right when plpython
loads. Backtrace below.
>>> Does plpython pass its regression tests for you (I'd suppose not)?
>>>
>>>
This thread being cross posted has made it a bit
confusing
Greg Stark wrote:
Nobody has ever suggested filtering out empty elements or dealing
specially with spaces or anything else like that. If you're talking
about that then you've missed the original question.
"Does anyone want t
On Tue, Mar 31, 2009 at 6:44 PM, justin wrote:
>
> Consider this. I have intelligent part numbers that need to be split apart
> to simplify searching and do math with.
>
> string_to_array(' F-2500-50 ', '-' ) ::int[]
Yeah, that's what I've said about three times. If you're building a
parser an
Greg Stark wrote:
On Tue, Mar 31, 2009 at 5:48 PM, justin wrote:
But consider this fails also
select string_to_array('1, , 3', ',' )::int[] => ERROR: invalid input
syntax for integer: " "
yet this works
select string_to_array('1, 2, 3',',')::int[]
Sure, and the an
On 3/31/09 9:45 AM, Emmanuel Cecchet wrote:
Yes, there is a good reason. As a trigger can update the tuple value,
this can change the routing decision. If you have a user trigger that
tries to change the key value after the partition choice has been made,
this will lead to an integrity constraint
Euler Taveira de Oliveira wrote:
> Tom Lane escreveu:
> > Alvaro Herrera writes:
> >> ... However, on HEAD this is crashing for me, and it's right when plpython
> >> loads. Backtrace below.
> >
> > Does plpython pass its regression tests for you (I'd suppose not)?
> >
> > For me on Fedora 10 x8
Zdenek Kotala writes:
> The main problem what I see here is that getopt and getopt_long works
> together. Use one from system and one ported is not good idea.
Well, the expected (and pretty-well-tested) case is that your system has
getopt but not getopt_long. I don't see any reason why using po
On Tue, Mar 31, 2009 at 5:48 PM, justin wrote:
>
> But consider this fails also
>
> select string_to_array('1, , 3', ',' )::int[] => ERROR: invalid input
> syntax for integer: " "
>
> yet this works
>
> select string_to_array('1, 2, 3',',')::int[]
Sure, and the analogous pair string_to_array('
Dne 31.03.09 18:21, Tom Lane napsal(a):
Zdenek Kotala writes:
Yeah correct, I overlooked that optreset is also defined as a extern.
There is updated patch.
On looking at this I still can't see how it's not broken. You are
effectively assuming that getopt_long.c must define those variables.
Emmanuel Cecchet writes:
> Yes, there is a good reason. As a trigger can update the tuple value,
> this can change the routing decision. If you have a user trigger that
> tries to change the key value after the partition choice has been made,
> this will lead to an integrity constraint violatio
Tom Lane escreveu:
> Alvaro Herrera writes:
>> ... However, on HEAD this is crashing for me, and it's right when plpython
>> loads. Backtrace below.
>
> Does plpython pass its regression tests for you (I'd suppose not)?
>
> For me on Fedora 10 x86_64, CVS HEAD plus python 2.5.2 passes regressio
Yes, there is a good reason. As a trigger can update the tuple value,
this can change the routing decision. If you have a user trigger that
tries to change the key value after the partition choice has been made,
this will lead to an integrity constraint violation which is probably
not what the
Sam Mason wrote:
string_to_array('',',')::INT[] => invalid input syntax for integer: ""
Which you don't get at the moment; although you do currently get it in
other common cases such as:
string_to_array('1,',',')::INT[]
If you want backwards compatible behaviour you could always bung a
N
Sam Mason wrote:
I'd expect 3,2,1 and 1.
That's also a disingenuous example; what would you expect back from:
select count_elements(string_to_array('butter,,milk',','))
I think the semantics you want is what you'd get from:
array_filter_blanks(string_to_array($1,$2))
where I defined "arr
Zdenek Kotala writes:
> Yeah correct, I overlooked that optreset is also defined as a extern.
> There is updated patch.
On looking at this I still can't see how it's not broken. You are
effectively assuming that getopt_long.c must define those variables.
But surely getopt_long.c should be assum
On Tue, Mar 31, 2009 at 4:34 PM, Sam Mason wrote:
>
> That's also a disingenuous example; what would you expect back from:
>
> select count_elements(string_to_array('butter,,milk',','))
>
> I think the semantics you want is what you'd get from:
>
> array_filter_blanks(string_to_array($1,$2))
>
>
Tom Lane wrote:
We already have system triggers -- the FK triggers. I don't think we've
had all that much trouble with them.
In the case of the FK triggers, it's intentional (and maybe even
documented) that users should be able to place their own triggers before
or after the FK triggers
On Mar 31, 2009, at 8:34 AM, Sam Mason wrote:
What do you really expect to be returned for things like
select count_elements(string_to_array('butter,tea,milk',','))
3 = {butter,tea,milk}
select count_elements(string_to_array('butter,tea',','))
2 = {butter,tea}
select count_elements(stri
Greg Stark wrote:
> On Tue, Mar 31, 2009 at 4:17 PM, Alvaro Herrera
> wrote:
> > Greg Stark wrote:
> >> Could the list admin please unsu*scribe Andreas Zeugswetter from the
> >> lists until he can fix his vacation-responder-gone-nuts?
> >
> > I've set him "nomail" on pgsql-hackers.
>
> Thanks. Is
On Tue, Mar 31, 2009 at 4:17 PM, Alvaro Herrera
wrote:
> Greg Stark wrote:
>> Could the list admin please unsubscribe Andreas Zeugswetter from the
>> lists until he can fix his vacation-responder-gone-nuts?
>
> I've set him "nomail" on pgsql-hackers.
Thanks. Is there a better address to reach lis
Alvaro Herrera writes:
> Nikhil Sontakke escribió:
>>> As triggers are executed in order of their names, we've prefixed the
>>> trigger names with "zz". This should work fine as long as no-one uses
>>> trigger-name which starts with "zz".
>> this seems a lot fragile...
> We already have system t
Greg Stark writes:
> On Tue, Mar 31, 2009 at 3:42 PM, Sam Mason wrote:
>> string_to_array('',',')::INT[] => invalid input syntax for integer: ""
> Oof. That's a good point.
Isn't that an argument in favor of the zero-size-array definition?
regards, tom lane
--
Sent v
On Tue, Mar 31, 2009 at 03:43:37PM +0100, Greg Stark wrote:
> On Tue, Mar 31, 2009 at 7:45 AM, Brendan Jurd wrote:
> > My first thought was that it should be a zero-element array, because
> > then the string_to_array() behaviour would conform to the notion that
> > it returns an array with 1 eleme
Heikki Linnakangas writes:
> Tom Lane wrote:
>> This isn't entirely trivial because it's presently expensive to
>> determine whether a table is someone else's temp table: it takes a
>> system catalog lookup. I'm not even sure that it'd be safe to have
>> the relcache do it and cache the result -
Greg Stark wrote:
> Could the list admin please unsubscribe Andreas Zeugswetter from the
> lists until he can fix his vacation-responder-gone-nuts?
I've set him "nomail" on pgsql-hackers.
> -- Forwarded message --
> From: Zeugswetter Andreas OSB sIT
> Date: Tue, Mar 31, 2009 at
On Tue, Mar 31, 2009 at 9:46 AM, Alvaro Herrera
wrote:
>>
>> AFAICS, we do not have any category like system triggers. So yeah, it would
>> have been nice to generate triggers with names (starting with __ for
>> example) for such special triggers. But I don't think we disallow
>> user-triggers sta
Could the list admin please unsubscribe Andreas Zeugswetter from the
lists until he can fix his vacation-responder-gone-nuts?
-- Forwarded message --
From: Zeugswetter Andreas OSB sIT
Date: Tue, Mar 31, 2009 at 3:44 PM
Subject: Abwesend: [HACKERS] [GENERAL] string_to_array with
Tom Lane wrote:
Heikki Linnakangas writes:
Tom Lane wrote:
A quick look at contrib/pgstattuple shows that it makes no effort
whatsoever to avoid reading temp tables belonging to other sessions.
contrib/pageinspect has the same bug. Not surprising as it was largely
inspired by pgstattuple.
Nikhil Sontakke escribió:
> > >> As triggers are executed in order of their names, we've prefixed the
> > >> trigger names with "zz". This should work fine as long as no-one uses
> > >> trigger-name which starts with "zz".
> >
> > this seems a lot fragile... why system generated triggers has to b
On Tue, Mar 31, 2009 at 3:42 PM, Sam Mason wrote:
>
> string_to_array('',',')::INT[] => invalid input syntax for integer: ""
Oof. That's a good point.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
On Tue, Mar 31, 2009 at 7:45 AM, Brendan Jurd wrote:
> My first thought was that it should be a zero-element array, because
> then the string_to_array() behaviour would conform to the notion that
> it returns an array with 1 element per string fragment bounded by the
> delimiter.
>
> However, I no
On Tue, Mar 31, 2009 at 05:45:33PM +1100, Brendan Jurd wrote:
> On Tue, Mar 31, 2009 at 2:26 PM, Tom Lane wrote:
> > Does anyone want to argue for keeping it the same? Or perhaps
> > argue that a zero-element array is a more sensible result than
> > a one-element array with one empty string? (It
Alvaro Herrera writes:
> Tom Lane wrote:
>> I can't remember having seen bugs of this type before.
> If we had had this defense in place, it would have been obvious that
> reindex and cluster were buggy. The code to skip temp tables was not
> there from the beginning.
I thought my memory was pr
Tom Lane wrote:
> The solution that seems most practical to me is to add a bool column
> to pg_class indicating "this is a temp table". Then, if that flag
> is set but it's not our own temp table (which we can tell easily),
> refuse to read. However, a patch of that size would take a little
> wh
Hi,
>
> >> As triggers are executed in order of their names, we've prefixed the
> >> trigger names with "zz". This should work fine as long as no-one uses
> >> trigger-name which starts with "zz".
> >>
>
> this seems a lot fragile... why system generated triggers has to be
> executed following th
Heikki Linnakangas writes:
> Tom Lane wrote:
>> A quick look at contrib/pgstattuple shows that it makes no effort
>> whatsoever to avoid reading temp tables belonging to other sessions.
> contrib/pageinspect has the same bug. Not surprising as it was largely
> inspired by pgstattuple.
Given the
Roman writes:
> db_server=# set client_encoding to 'alt';
> server closed the connection unexpectedly
>This probably means the server terminated abnormally
>before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
> Is anyone can t
> elog(NOTICE,"ALT_TO_KOI8");
> unsigned char *src = PG_GETARG_CSTRING(*2*);
> unsigned char *dest = PG_GETARG_CSTRING(*3*);
> int len = PG_GETARG_INT32(*4*);
I don't think this is even valid C code? Confused.
> Is anyone can tell me what I'm doing wrong?
select pg_backend_pi
Hello!
There is a database in KOI8-R encoding. And we have a client who is
querying the database:
set client_encoding TO 'ALT'
and then he write some data into the database.
I have a problem with some symbols which exists in ALT encoding and
which are absent in KOI8-R encoding. As result, duri
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Does plpython pass its regression tests for you (I'd suppose not)?
>
> > Doh. Silly me. It does pass the regression tests, all six of them. I
> > guess it's trying to load the unicode stuff that it crashes, not
> > plpython itse
Dne 31.03.09 04:55, Tom Lane napsal(a):
Zdenek Kotala writes:
I attached a fix. Only problem what I see there is getopt_long.h which
contains
I'm more concerned about the "static int optreset", which is 100%
guaranteed to break things.
Yeah correct, I overlooked that optreset is also defin
On Tue, Mar 31, 2009 at 2:20 PM, Heikki Linnakangas
wrote:
>> This is exactly what happened, and temporary tables belonging to other
>> sessions where fed to pgstattuple.
>
> +1 for throwing an error. That's what we do for views, composite types, and
> GIN indexes as well. If you want to write a
Stuart Bishop wrote:
On Tue, Mar 31, 2009 at 11:20 AM, Tom Lane wrote:
A quick look at contrib/pgstattuple shows that it makes no effort
whatsoever to avoid reading temp tables belonging to other sessions.
So even if that wasn't Stuart's problem (and I'll bet it was), this
is quite broken.
Th
Tom Lane wrote:
A quick look at contrib/pgstattuple shows that it makes no effort
whatsoever to avoid reading temp tables belonging to other sessions.
contrib/pageinspect has the same bug. Not surprising as it was largely
inspired by pgstattuple.
--
Heikki Linnakangas
EnterpriseDB http
69 matches
Mail list logo
