Thank you for your reply to the question. If it was chosen to reproduce the
actual semantics of the expression in various contexts, I think the bpchar
type of 'abc'::bpchar is surprised me. Is it really important to show the
'bpchar' if there is no any explicit casting for the column default value.
Greg Stark writes:
> Hmm. One case where this logic might not be true would be if the dll
> relies on c++ style static initializers and destructors. In that case
> it may very well leave hooks in place in case of an error and only
> clean them up when you call dlclose().
Interesting point,
Pavel Stehule writes:
> Maybe an safe minimum is cleaning symbols table without closing
> library. Then the code from lib will be accessible, but functionality
> will be disabled (for Postgres)?
If the library doesn't get added to the list in dfmgr.c, we'll never
look for symbols within it anyway
I think I see the reason for the recent report of $SUBJECT.
Starting with a client_encoding different from server_encoding,
change it to something else and then roll back, for example
u8=# show server_encoding ;
server_encoding
-
UTF8
(1 row)
u8=# set client_encoding to latin1;
2009/4/2 Tom Lane :
> Pavel Stehule writes:
>> 2009/4/2 Tom Lane :
>>> So I'm thinking this is really unnecessary and we should leave well
>>> enough alone.
>
>> I see it. I thing , an safety of this exception should be solved only
>> by programmer. It's important to release all hooks, and then ra
Hmm. One case where this logic might not be true would be if the dll
relies on c++ style static initializers and destructors. In that case
it may very well leave hooks in place in case of an error and only
clean them up when you call dlclose().
--
Greg
On 1 Apr 2009, at 22:58, Tom Lane
Hi all:
I’ve found a bug about hstore, example below:
CREATE TABLE temp_table (
dcp smallint,
atext hstore
);
COPY temp_table (dcp, atext) FROM stdin;
800 ""=>NULL
\.
Then do the sql twice below :
Select * from temp_table;
Pg(version 8.3 and above) will coredump, bac
Pavel Stehule writes:
> 2009/4/2 Tom Lane :
>> So I'm thinking this is really unnecessary and we should leave well
>> enough alone.
> I see it. I thing , an safety of this exception should be solved only
> by programmer. It's important to release all hooks, and then raise an
> exception. It is in
2009/4/2 Tom Lane :
> Pavel Stehule writes:
>> attached patch allows raising exception from _PG_init function as was
>> discussed before.
>
> I fooled around with this and came up with the attached improved
> version, which allows reporting the full error status. However,
> after thinking some mo
Hitoshi Harada writes:
> I don't think advising or documenting such restriction to the future
> programmer is a good idea from the point of encapsulation. I've come
> up with an idea, that the read pointers remember their last slot as
> you suggest and materialize it when another slot comes in
> t
Tom Lane wrote:
I'm starting to vacillate again. It's clear that for the purposes
of string_to_array, an empty input string is fundamentally ambiguous:
it could mean a list of no things, or a list of one empty thing.
Agreed. Of the two, a list of one empty thing makes string_to_array
closer
Pavel Stehule writes:
> attached patch allows raising exception from _PG_init function as was
> discussed before.
I fooled around with this and came up with the attached improved
version, which allows reporting the full error status. However,
after thinking some more I feel that this is probably
On Wed, Apr 01, 2009 at 05:41:53PM -0400, Andrew Dunstan wrote:
> Richard Boulton wrote:
>> As I understand it, ASL 2 is incompatible with GPL 2, at least according to
>> the FSF. This would be a showstopper problem for me.
>
> Er, what does Postgres have that is covered by GPL2?
I think cross po
"Kevin Grittner" writes:
> Where does GPL come into it? (I hadn't seen that mentioned before for
> either product.)
Keep in mind that you're seeing some fraction of the discussion on
snowball-discuss (whatever is from people also subscribed to
pgsql-hackers; everything else is stuck in the moder
On Wed, Apr 1, 2009 at 11:44 PM, Kevin Grittner
wrote:
> Where does GPL come into it? (I hadn't seen that mentioned before for
> either product.)
Richard is one of the developers of Snowball so he might want to keep
its license compatible with GPL2.
Moreover, Snowball is used by a lot of projec
On Apr 1, 2009, at 4:51 PM, Oleg Bartunov wrote:
Grant,
I'm originator of this thread and PostgreSQL is also a big user of the
Snowball project, so we also are very interested in the vital
activity of the project. However, I see issue with license, which is
currently BSD and this allows us
I got interested in why trivial window functions looked really slow,
when using this example in the regression database:
regression=# explain analyze select *, row_number() over (order by unique2)
from tenk1;
QUERY PLAN
>>> Richard Boulton wrote:
> On Wed, Apr 01, 2009 at 05:10:01PM -0400, Grant Ingersoll wrote:
>> No, it would have to be ASL 2, but that is pretty similar to BSD,
no?
>> (caveat: IANAL) i.e non-viral, free to use however you want, just
>> don't take credit for it. Everything I've read says
Richard Boulton wrote:
On Wed, Apr 01, 2009 at 05:10:01PM -0400, Grant Ingersoll wrote:
No, it would have to be ASL 2, but that is pretty similar to BSD, no?
(caveat: IANAL) i.e non-viral, free to use however you want, just
don't take credit for it. Everything I've read says the two ar
On Wed, Apr 1, 2009 at 5:22 PM, Tom Lane wrote:
> Or we could stick to the current behavior and say "use COALESCE() to
> resolve the ambiguity, if you need to".
If there's no consensus on changing the behavior, it's probably better
to be backward compatible than not.
...Robert
--
Sent via pgsq
On Wed, Apr 1, 2009 at 3:49 PM, Sam Mason wrote:
> On Wed, Apr 01, 2009 at 03:19:23PM -0400, Robert Haas wrote:
>> On Wed, Apr 1, 2009 at 12:52 PM, David E. Wheeler
>> wrote:
>> > Well, I'd just point out that the return value of string_to_array() is
>> > text[]. Thus, this is not a problem with
On Wed, Apr 01, 2009 at 05:10:01PM -0400, Grant Ingersoll wrote:
> No, it would have to be ASL 2, but that is pretty similar to BSD, no?
> (caveat: IANAL) i.e non-viral, free to use however you want, just
> don't take credit for it. Everything I've read says the two are
> completely compati
Robert Haas writes:
> If you take 0 items of any type whatsoever and join them together with
> commas, you will get the empty string. It is also true that if you
> join 1 item together with commas, you will get that item back, and if
> that item is the empty string, you will now have the empty st
Martin Gainty wrote:
Split strings into array elements using provided
delimiter
string_to_array('xx~^~yy~^~zz', '~^~')
output: {xx,yy,zz}
http://www.postgresql.org/docs/8.3/interactive/functions-array.html
Sorry thats not the question i'm asking.
We are debating if it makes
Grant,
I'm originator of this thread and PostgreSQL is also a big user of the
Snowball project, so we also are very interested in the vital
activity of the project. However, I see issue with license, which is
currently BSD and this allows us to use snowball in PostgreSQL (which
is also BSD lice
Split strings into array elements using provided delimiter
string_to_array('xx~^~yy~^~zz', '~^~')
output: {xx,yy,zz}
http://www.postgresql.org/docs/8.3/interactive/functions-array.html
?
Martin
__
Disclaimer and confidentiality note
This messa
If someone can show me a real world example this logic simplifies the
code and has more uses I'll bite
I just presently can't see how this works better.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
On Wed, Apr 01, 2009 at 03:19:23PM -0400, Robert Haas wrote:
> On Wed, Apr 1, 2009 at 12:52 PM, David E. Wheeler
> wrote:
> > Well, I'd just point out that the return value of string_to_array() is
> > text[]. Thus, this is not a problem with string_to_array(), but a casting
> > problem from text[
On Wed, Apr 1, 2009 at 1:05 PM, justin wrote:
> I'm still a hold out, We are taking a string putting it into a array based
> on a delimiter. That is very simple and straight forward. Yet many argue
> if we want to cast this into another data type the function should deal with
> in limited cases
On Wed, Apr 1, 2009 at 12:52 PM, David E. Wheeler wrote:
> Well, I'd just point out that the return value of string_to_array() is
> text[]. Thus, this is not a problem with string_to_array(), but a casting
> problem from text[] to int[]. Making string_to_array() return a NULL for
> this case to ma
On Wed, Apr 01, 2009 at 07:40:16PM +0100, Greg Stark wrote:
> The existing behaviour of returning NULL is the only "consistent"
> choice since the correct value is "unknown". And one could argue that
> it's easier to replace NULL with the correct value if the programmer
> knows using coalesce than
Tom Lane wrote:
Hiroshi Inoue writes:
Heikki Linnakangas wrote:
I just tried that, and it seems that gettext() does transliteration, so
any characters that have no counterpart in the database encoding will be
replaced with something similar, or question marks.
It doesn't occur in the curre
"Vincze, Tamas" writes:
> Tom Lane wrote:
>> "Vincze, Tamas" writes:
> + * Note that it may still select BLOBs that have no comment if
> a pg_description row's objoid
> + * matches a BLOB's loid, but references an object contained in
> a different system catalog,
>>
>
On Wed, Apr 1, 2009 at 6:23 PM, David E. Wheeler wrote:
> Right, it's making a special case of '', which does seem rather inconsistent
> to me.
"David E. Wheeler" writes:
> On Apr 1, 2009, at 10:05 AM, justin wrote:
>
>> string_to_array('',',')::INT[] works as proposed
>>
>> But
>> string_to_
On Wed, Apr 01, 2009 at 10:23:18AM -0700, David E. Wheeler wrote:
> On Apr 1, 2009, at 10:05 AM, justin wrote:
> >string_to_array('',',')::INT[] works as proposed
> >
> >But
> >string_to_array(',,,', ',' )::INT[] Fails
> >or
> >string_to_array('1,2,,4', ',' )::INT[] Fails .
> >
> >
> >I'm trying
Tom Lane wrote:
"Vincze, Tamas" writes:
+* Note that it may still select BLOBs that have no comment if
a pg_description row's objoid
+* matches a BLOB's loid, but references an object contained in
a different system catalog,
... seems like that would be easy
On Tue, Mar 31, 2009 at 11:33:26PM +0300, Peter Eisentraut wrote:
> 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 th
Hiroshi Inoue writes:
> Heikki Linnakangas wrote:
>> I just tried that, and it seems that gettext() does transliteration, so
>> any characters that have no counterpart in the database encoding will be
>> replaced with something similar, or question marks.
> It doesn't occur in the current Windo
On Apr 1, 2009, at 10:05 AM, justin wrote:
string_to_array('',',')::INT[] works as proposed
But
string_to_array(',,,', ',' )::INT[] Fails
or
string_to_array('1,2,,4', ',' )::INT[] Fails .
I'm trying to understand the difference between a empty string to a
string with many blank entries
Heikki Linnakangas wrote:
Tom Lane wrote:
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 mag
On Apr 1, 2009, at 10:09 AM, Tom Lane wrote:
Thus, this is not a problem with string_to_array(), but a
casting problem from text[] to int[].
Nonsense. The question is whether string_to_array is meant to be
useful
for lists of anything except text. I agree you could argue that it
isn't. B
"David E. Wheeler" writes:
> Well, I'd just point out that the return value of string_to_array() is
> text[].
True...
> Thus, this is not a problem with string_to_array(), but a
> casting problem from text[] to int[].
Nonsense. The question is whether string_to_array is meant to be useful
Tom Lane wrote:
Robert Haas writes:
On Tue, Mar 31, 2009 at 10:44 AM, Greg Stark wrote:
On Tue, Mar 31, 2009 at 3:42 PM, Sam Mason wrote:
string_to_array('',',')::INT[] => invalid input syntax for integer: ""
Oof. That
On Apr 1, 2009, at 9:02 AM, Tom Lane wrote:
+1. I find this argument much more compelling than anything else
that's been offered up so far.
Yeah. It seems to me that if you consider only the case where the
array
elements are text, there's a weak preference for considering '' to
be a
sing
On Sat, Mar 28, 2009 at 12:25 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane wrote:
>>> Both of those things are related to 8.4 feature changes, so we should
>>> either do them now or decide we won't do them.
>
>> Well, "Should we have a LOCALE option in
Robert Haas writes:
> On Tue, Mar 31, 2009 at 10:44 AM, Greg Stark wrote:
>> 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.
> +1. I find this argument much more compelling than anyth
"Vincze, Tamas" writes:
> + * Note that it may still select BLOBs that have no comment if
> a pg_description row's objoid
> + * matches a BLOB's loid, but references an object contained in
> a different system catalog,
... seems like that would be easy to fix ...
On Tue, Mar 31, 2009 at 10:44 AM, Greg Stark wrote:
> 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.
+1. I find this argument much more compelling than anything else
that's been offer
Hi,
We have a database with tens of millions of large objects, none
of them with any comments. When running pg_dump it spends several
hours looking for BLOB comments, finding none at the end but taxing
the server so much that the simplest query takes seconds to complete.
The attached patch fixes
[ oops, forgot to send this to -hackers before ]
On Tue, Mar 31, 2009 at 05:08:45PM +0100, Greg Stark wrote:
> Both interpretations are clearly consistent but it depends on whether
> you think it's a bunch of text strings concatenated together or if
> it's a list of objects.
>
> The example of s
2009/4/1 Alvaro Herrera :
> Pavel Stehule escribió:
>> Hello
>>
>> I am sending samples of transformation hook modules. One module is
>> JSON support:.
>>
>> From these modules only JSON support has general usage - so only JSON
>> should be integrated to core.
>
> I'm only seeing trivial examples b
Tom Lane wrote:
> Alvaro Herrera writes:
> > One problem with this idea is that it may be hard to coerce gettext into
> > putting a particular string at the top of the file :-(
>
> I doubt we can, which is why the documentation needs to tell translators
> about it.
I doubt that documenting the
Pavel Stehule escribió:
> Hello
>
> I am sending samples of transformation hook modules. One module is
> JSON support:.
>
> From these modules only JSON support has general usage - so only JSON
> should be integrated to core.
I'm only seeing trivial examples below, where you form the JSON object
Tom Lane wrote:
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
2009/4/1 Werner Echezuria :
> As you can see if someone do this: SELECT * FROM table WHERE
> field=some_value ORDER BY grmemb, postgresql creates a new target entry and
> then assigned to the targetlist as a sort node. I know that it creates the
> node on the parser, but it does not work, it seems
55 matches
Mail list logo
