Alvaro Herrera writes:
> Tom Lane wrote:
>> Or we could increase the size of hstore values so as to provide more
>> than 32 bits total for this, but that would presumably be pessimal for
>> all existing applications; there is evidently no one using more than
>> 64K, or we'd have heard complaints b
I wrote:
> Andrew Dunstan writes:
>> In my original patch, I looked at all the dependencies of a candidate
>> item ansd compared them with the dependencies of the running items to
>> see if there was a potential locking clash. However, Tom in his
>> admirable reworking of my patch, restricted t
Tom Lane wrote:
> Or we could increase the size of hstore values so as to provide more
> than 32 bits total for this, but that would presumably be pessimal for
> all existing applications; there is evidently no one using more than
> 64K, or we'd have heard complaints before.
Would it work to allo
I wrote:
> If we wanted to keep the lengths in the same 32 bits they presumably
> occupy now, what about splitting 8/24 (=> 255 bytes for key, 24MB for
> value)?
Sigh, fingers faster than brain today. A 24-bit length field could
represent lengths up to 16MB, not 24MB. Still, it seems like a
reas
On Mar 13, 2009, at 2:35 PM, Tom Lane wrote:
Is a more Perlish syntax out of the question?
Yes. SQL is not Perl.
You mean all this time I thought I was writing Perl when I was using
PostgreSQL, and it turns out that it's *not* Perl? That explains the
strange lack of sigils.
Thanks for
"David E. Wheeler" writes:
> Is a more Perlish syntax out of the question?
Yes. SQL is not Perl.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hacke
On Mar 13, 2009, at 2:26 PM, Andrew Gierth wrote:
David> Is a more Perlish syntax out of the question?
Yes. Sorry.
David> SELECT ('a=>1,b=>2,c=>3'::hstore)['a', 'b'];
David> -- returns '{1,2}'
That would require integrating hstore into core - array subscripting
isn't a user-definable operat
> "David" == "David E Wheeler" writes:
>> select ('a=>1,b=>2,c=>3'::hstore) -> ARRAY['a','b'];
>> -- returns '{1,2}'
>>
>> select ('a=>1,b=>2,c=>3'::hstore) => ARRAY['a','b'];
>> -- returns 'a=>1,b=>2'
>>
>> (by analogy to the existing operators -> for lookup and => for
>> construct
On Mar 13, 2009, at 1:21 PM, Andrew Gierth wrote:
I'm thinking that (hstore -> text[]) should probably return
text[],
and maybe (hstore => text[]) returning hstore?
i.e.
select ('a=>1,b=>2,c=>3'::hstore) -> ARRAY['a','b'];
-- returns '{1,2}'
select ('a=>1,b=>2,c=>3'::hstore) => ARRAY['a','
> "Tom" == Tom Lane writes:
Tom> As for truncation rather than throwing an error, I'd argue that
Tom> that's a flat-out bug and the fix deserves back-patching.
Separate patch for that part then?
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
> "David" == "David E Wheeler" writes:
> On Mar 13, 2009, at 11:06 AM, Andrew Gierth wrote:
>> If there's any other features that people find notably missing
>> from hstore, I could stick them in too; any requests?
David> Can you create slices? That is, create a new hstore as a
David> s
"David E. Wheeler" writes:
> On Mar 13, 2009, at 11:06 AM, Andrew Gierth wrote:
>> Also, hstore has an (undocumented) limit of 65535 bytes for keys and
>> values, and it does not behave very cleanly when given longer values
>> (it truncates them mod 2^16, rather than erroring). That gives rise to
Alvaro Herrera writes:
> Heikki Linnakangas wrote:
>> Alvaro Herrera wrote:
>>> Optionally compressing the values would be nice ...
>>
>> The whole Datum will be toasted/compressed if it gets large enough. Is
>> that not enough?
> It doesn't always gets large enough, and there's no way to cont
On Mar 13, 2009, at 11:06 AM, Andrew Gierth wrote:
If there's any other features that people find notably missing from
hstore, I could stick them in too; any requests?
Can you create slices? That is, create a new hstore as a subset of an
existing hstore?
Also, hstore has an (undocumented)
Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
>> Andrew Gierth wrote:
>>> I have a patch almost done that adds some obvious but currently
>>> missing functionality to hstore, specifically the ability to construct
>>> an hstore from a record, and the ability to construct one from a pair
>>> of a
Alvaro Herrera wrote:
Andrew Gierth wrote:
I have a patch almost done that adds some obvious but currently
missing functionality to hstore, specifically the ability to construct
an hstore from a record, and the ability to construct one from a pair
of arrays.
If there's any other features that p
Andrew Gierth wrote:
> I have a patch almost done that adds some obvious but currently
> missing functionality to hstore, specifically the ability to construct
> an hstore from a record, and the ability to construct one from a pair
> of arrays.
>
> If there's any other features that people find no
I have a patch almost done that adds some obvious but currently
missing functionality to hstore, specifically the ability to construct
an hstore from a record, and the ability to construct one from a pair
of arrays.
If there's any other features that people find notably missing from
hstore, I coul
Josh Berkus writes:
>>> How much of this pain would go away if we changed over to the arguably
>>> correct (as in Or*cle does it that way) scoping for names, wherein the
>>> parser first tries to match a name against column names of tables of the
>>> current SQL statement, and only failing that lo
Most of the Solaris buildfarm members are unhappy this morning.
It looks like the ones that are busted have --enable-dtrace,
which points the finger at the dtrace probe changes I made yesterday:
http://archives.postgresql.org/pgsql-committers/2009-03/msg00079.php
Those changes work on Linux and OS
On Fri, Mar 13, 2009 at 1:44 PM, Kev wrote:
> On Mar 13, 9:30 am, dp...@pgadmin.org (Dave Page) wrote:
>> On Fri, Mar 13, 2009 at 1:19 PM, Kev wrote:
>> > On the 2009-01-01 win32 release, I noticed I could no longer debug,
>>
>> Temporary bug that's since been resolved. Sorry 'bout that.
>
> Oh,
On Mar 13, 9:30 am, dp...@pgadmin.org (Dave Page) wrote:
> On Fri, Mar 13, 2009 at 1:19 PM, Kev wrote:
> > On the 2009-01-01 win32 release, I noticed I could no longer debug,
>
> Temporary bug that's since been resolved. Sorry 'bout that.
Oh, no worries, thanks for the reply. I notice there's no
On Fri, Mar 13, 2009 at 1:19 PM, Kev wrote:
> On the 2009-01-01 win32 release, I noticed I could no longer debug,
> like when I'd set a breakpoint I'd immediately get the error message:
>
> syntax error at or near ","
> LINE 1: SELECT * FROM pldbg_set_global_breakpoint(, 55208, NULL,
> NUL...
>
>
On the 2009-01-01 win32 release, I noticed I could no longer debug,
like when I'd set a breakpoint I'd immediately get the error message:
syntax error at or near ","
LINE 1: SELECT * FROM pldbg_set_global_breakpoint(, 55208, NULL,
NUL...
...and the output pane of the debugger would show:
row num
Oleg Bartunov writes:
> I'm also wonder if we're on the right way, since the only serious
> issue with indexscan was possible problem with slaves, but read-only slaves
> delayed to 8.5, so this is not an issue now. In 8.5 development cycle we'll
> certainly return to this issue, so why do we disa
On Thu, 5 Mar 2009, Robert Haas wrote:
On Thu, Mar 5, 2009 at 6:35 PM, Tom Lane wrote:
Attached is the remainder of the patch with relatively minor fixes.
The main change I made is to get rid of the changes in gincostestimate;
I agree with Robert that it's probably inappropriate to consider th
Guillaume Smet writes:
> On Fri, Mar 13, 2009 at 2:39 AM, Josh Berkus wrote:
>> SET ROLE special WITH SETTINGS
>>
>> ... or similar; I'd need to find an existing keyword which works.
>
> Perhaps something like "SET ROLE special NEW SESSION;".
>
> It solves a problem mentioned by Tom as it's very
On Fri, Mar 13, 2009 at 2:39 AM, Josh Berkus wrote:
> SET ROLE special WITH SETTINGS
>
> ... or similar; I'd need to find an existing keyword which works.
Perhaps something like "SET ROLE special NEW SESSION;".
It solves a problem mentioned by Tom as it's very clear that it's a
new session so wh
28 matches
Mail list logo
