On Fri, Mar 13, 2009 at 2:39 AM, Josh Berkus j...@agliodbs.com 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
Guillaume Smet guillaume.s...@gmail.com writes:
On Fri, Mar 13, 2009 at 2:39 AM, Josh Berkus j...@agliodbs.com 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
On Thu, 5 Mar 2009, Robert Haas wrote:
On Thu, Mar 5, 2009 at 6:35 PM, Tom Lane t...@sss.pgh.pa.us 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
Oleg Bartunov o...@sai.msu.su 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
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
On Fri, Mar 13, 2009 at 1:19 PM, Kev kevinjamesfi...@gmail.com 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,
On Mar 13, 9:30 am, dp...@pgadmin.org (Dave Page) wrote:
On Fri, Mar 13, 2009 at 1:19 PM, Kev kevinjamesfi...@gmail.com 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.
On Fri, Mar 13, 2009 at 1:44 PM, Kev kevinjamesfi...@gmail.com wrote:
On Mar 13, 9:30 am, dp...@pgadmin.org (Dave Page) wrote:
On Fri, Mar 13, 2009 at 1:19 PM, Kev kevinjamesfi...@gmail.com wrote:
On the 2009-01-01 win32 release, I noticed I could no longer debug,
Temporary bug that's since
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
Josh Berkus j...@agliodbs.com 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
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
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 notably
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
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 arrays.
If
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
Alvaro Herrera alvhe...@commandprompt.com 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
David E. Wheeler da...@kineticode.com 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
David == David E Wheeler da...@kineticode.com 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
Tom == Tom Lane t...@sss.pgh.pa.us 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
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','b'];
--
David == David E Wheeler da...@kineticode.com 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
construction)
David Is
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 operation.
David E. Wheeler da...@kineticode.com 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:
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
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
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 allow
I wrote:
Andrew Dunstan and...@dunslane.net 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,
Alvaro Herrera alvhe...@commandprompt.com 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
28 matches
Mail list logo
