On Tue, Jun 21, 2011 at 5:50 PM, Alexey Klyukin wrote:
> On Jun 21, 2011, at 9:58 PM, Noah Misch wrote:
>> A pg_regress test needs stable output, so we would do it roughly like this:
>>
>> CREATE TEMP TABLE relstorage AS SELECT 0::regclass AS oldnode;
>> ...
>> UPDATE relstorage
On Jun 21, 2011, at 9:58 PM, Noah Misch wrote:
>
> A pg_regress test needs stable output, so we would do it roughly like this:
>
> CREATE TEMP TABLE relstorage AS SELECT 0::regclass AS oldnode;
> ...
> UPDATE relstorage SET oldnode =
> (SELECT relfilenode FROM pg
On Tue, Jun 21, 2011 at 06:31:44PM +0300, Alexey Klyukin wrote:
> Here is my review of this patch.
Thanks!
> The patch applies cleanly to the HEAD, produces no additional warnings. It
> doesn't include additional regression tests. One can include a test, using the
> commands like the ones includ
Hi,
On Jun 19, 2011, at 2:10 PM, Noah Misch wrote:
> On Sat, Jun 18, 2011 at 11:32:20PM -0400, Robert Haas wrote:
>> On Sat, Jun 18, 2011 at 11:12 PM, Robert Haas wrote:
>>> On Sat, Jun 18, 2011 at 11:06 PM, Noah Misch wrote:
On Sat, Jun 18, 2011 at 10:57:13PM -0400, Robert Haas wrote:
>>>
On Sat, Jun 18, 2011 at 11:32:20PM -0400, Robert Haas wrote:
> On Sat, Jun 18, 2011 at 11:12 PM, Robert Haas wrote:
> > On Sat, Jun 18, 2011 at 11:06 PM, Noah Misch wrote:
> >> On Sat, Jun 18, 2011 at 10:57:13PM -0400, Robert Haas wrote:
> >>> On Sat, Jun 11, 2011 at 5:13 PM, Noah Misch wrote:
>
On Sat, Jun 18, 2011 at 11:12 PM, Robert Haas wrote:
> On Sat, Jun 18, 2011 at 11:06 PM, Noah Misch wrote:
>> On Sat, Jun 18, 2011 at 10:57:13PM -0400, Robert Haas wrote:
>>> On Sat, Jun 11, 2011 at 5:13 PM, Noah Misch wrote:
>>> > Sounds good. ?Updated patch attached, incorporating your ideas.
On Sat, Jun 18, 2011 at 11:06 PM, Noah Misch wrote:
> On Sat, Jun 18, 2011 at 10:57:13PM -0400, Robert Haas wrote:
>> On Sat, Jun 11, 2011 at 5:13 PM, Noah Misch wrote:
>> > Sounds good. ?Updated patch attached, incorporating your ideas. ?Before
>> > applying
>> > it, run this command to update
On Sat, Jun 18, 2011 at 10:57:13PM -0400, Robert Haas wrote:
> On Sat, Jun 11, 2011 at 5:13 PM, Noah Misch wrote:
> > Sounds good. ?Updated patch attached, incorporating your ideas. ?Before
> > applying
> > it, run this command to update the uninvolved pg_proc.h DATA entries:
> > ?perl -pi -e 's/
On Sat, Jun 11, 2011 at 5:13 PM, Noah Misch wrote:
> Sounds good. Updated patch attached, incorporating your ideas. Before
> applying
> it, run this command to update the uninvolved pg_proc.h DATA entries:
> perl -pi -e 's/PGUID(\s+\d+){4}/$& 0/' src/include/catalog/pg_proc.h
This doesn't qui
On Sat, Jun 11, 2011 at 03:03:18PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > Good points. I'm thinking, then, add an Expr argument to
> > simplify_function()
> > and have the CoerceViaIO branch of eval_const_expressions_mutator() pass
> > NULL
> > for both its simplify_function() calls.
Noah Misch writes:
> Good points. I'm thinking, then, add an Expr argument to simplify_function()
> and have the CoerceViaIO branch of eval_const_expressions_mutator() pass NULL
> for both its simplify_function() calls. If simplify_function() gets a NULL
> Expr
> for a function that has a protr
On Sat, Jun 11, 2011 at 02:11:55PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > We originally discussed having the transform function take and return Expr
> > nodes. It turns out that simplify_function() does not have the Expr,
> > probably
> > because the particular choice of node type among
Noah Misch writes:
> We originally discussed having the transform function take and return Expr
> nodes. It turns out that simplify_function() does not have the Expr, probably
> because the particular choice of node type among the many that can convey a
> function call does not matter to it. The
On Fri, Jun 03, 2011 at 10:43:17AM -0500, Jim Nasby wrote:
> On Jun 3, 2011, at 10:11 AM, Alexey Klyukin wrote:
> >> Is your interest in cheap varchar(N)->varchar(N+M) conversions
> >> specifically, or
> >> in some broader application of this facility?
> >
> > Exactly varchar conversions.
>
> Wh
On Fri, Jun 3, 2011 at 11:43 AM, Jim Nasby wrote:
> On Jun 3, 2011, at 10:11 AM, Alexey Klyukin wrote:
>>> Is your interest in cheap varchar(N)->varchar(N+M) conversions
>>> specifically, or
>>> in some broader application of this facility?
>>
>> Exactly varchar conversions.
>
> Why limit it to v
Jim Nasby wrote:
> The only challenge I see is numeric; we'd need to ensure that both
> size and precision are not decreasing.
To be picky, wouldn't that need to be "neither (precision - scale)
nor scale is decreasing"?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
On Jun 3, 2011, at 10:11 AM, Alexey Klyukin wrote:
>> Is your interest in cheap varchar(N)->varchar(N+M) conversions specifically,
>> or
>> in some broader application of this facility?
>
> Exactly varchar conversions.
Why limit it to varchar? Shouldn't we be able to do this for any varlena? The
Hi,
On Jun 2, 2011, at 10:22 PM, Noah Misch wrote:
> Hi Alexey,
>
...
> Is your interest in cheap varchar(N)->varchar(N+M) conversions specifically,
> or
> in some broader application of this facility?
Exactly varchar conversions.
>
> Thanks for volunteering to review; that will be a big hel
Hi Alexey,
On Thu, Jun 02, 2011 at 05:08:51PM +0300, Alexey Klyukin wrote:
> Looks like this thread has silently died out. Is there an agreement on the
> syntax and implementation part? We (CMD) have a customer, who is interested in
> pushing this through, so, if we have a patch, I'd be happy to a
On May 24, 2011, at 12:15 AM, Noah Misch wrote:
> On Mon, May 23, 2011 at 03:01:40PM -0400, Tom Lane wrote:
>> Noah Misch writes:
>>> Good deal. Given that conclusion, the other policy decision I anticipate
>>> affecting this particular patch is the choice of syntax. Presumably, it
>>> will b
On Mon, May 23, 2011 at 03:01:40PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > Good deal. Given that conclusion, the other policy decision I anticipate
> > affecting this particular patch is the choice of syntax. Presumably, it
> > will be
> > a new common_func_opt_item. When I last looked
On Mon, May 23, 2011 at 02:53:01PM -0400, Robert Haas wrote:
> On Mon, May 23, 2011 at 2:46 PM, Noah Misch wrote:
> > On Mon, May 23, 2011 at 02:11:39PM -0400, Robert Haas wrote:
> >> On Mon, May 23, 2011 at 1:53 PM, Tom Lane wrote:
> >> > Maybe. ?But casts would be the least of our concerns if w
Greg Stark writes:
> This was the thing that concerned me. If anyone wants to add this
> feature for a new data type they're going to have to understand and
> tie their code to all this internal parser node stuff. That means
> their code will be much more closely tied to a specific version, will
>
On Mon, May 23, 2011 at 12:01 PM, Tom Lane wrote:
> Given that the helper function is going to have a
> signature along the lines of "(internal, internal) -> internal", it's
> going to be difficult for anyone to use it for non-builtin functions
> anyhow.
I hate to go around in circles on this bu
Noah Misch writes:
> Good deal. Given that conclusion, the other policy decision I anticipate
> affecting this particular patch is the choice of syntax. Presumably, it will
> be
> a new common_func_opt_item. When I last looked at the keywords list and tried
> to come up with something, these w
On Mon, May 23, 2011 at 2:46 PM, Noah Misch wrote:
> On Mon, May 23, 2011 at 02:11:39PM -0400, Robert Haas wrote:
>> On Mon, May 23, 2011 at 1:53 PM, Tom Lane wrote:
>> > Maybe. ?But casts would be the least of our concerns if we were trying
>> > to change the column type. ?Changing typmod doesn'
On Mon, May 23, 2011 at 02:11:39PM -0400, Robert Haas wrote:
> On Mon, May 23, 2011 at 1:53 PM, Tom Lane wrote:
> > Maybe. ?But casts would be the least of our concerns if we were trying
> > to change the column type. ?Changing typmod doesn't affect the set of
> > operations that could be applied
On Mon, May 23, 2011 at 1:53 PM, Tom Lane wrote:
> Maybe. But casts would be the least of our concerns if we were trying
> to change the column type. Changing typmod doesn't affect the set of
> operations that could be applied to a column, whereas changing type
> surely does.
OK, this is the cr
Robert Haas writes:
> On Mon, May 23, 2011 at 1:21 PM, Tom Lane wrote:
>> ... But I remain of the opinion that that's the wrong place
>> to put it.
> So you said here:
> http://archives.postgresql.org/pgsql-hackers/2011-01/msg02575.php
> http://archives.postgresql.org/pgsql-hackers/2011-01/msg0
On Mon, May 23, 2011 at 1:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, May 23, 2011 at 12:42 PM, Noah Misch wrote:
>>> There were two proposals on the table:
>>>
>>> 1. Attach a "f(from_typmod, to_typmod, is_explicit) RETURNS boolean"
>>> function
>>> to the pg_cast; call it in fin
Robert Haas writes:
> On Mon, May 23, 2011 at 12:42 PM, Noah Misch wrote:
>> There were two proposals on the table:
>>
>> 1. Attach a "f(from_typmod, to_typmod, is_explicit) RETURNS boolean" function
>> to the pg_cast; call it in find_coercion_pathway()
>> 2. Attach a "f(FuncExpr) RETURNS Expr
On Mon, May 23, 2011 at 12:42 PM, Noah Misch wrote:
> I'd like to revive the discussion that arose during the last CommitFest over
> the proper design for identifying no-op length coercions like varchar(4) ->
> varchar(8). Here is the root of the original debate:
>
> http://archives.postgresql.o
I'd like to revive the discussion that arose during the last CommitFest over
the proper design for identifying no-op length coercions like varchar(4) ->
varchar(8). Here is the root of the original debate:
http://archives.postgresql.org/message-id/20110109220353.gd5...@tornado.leadboat.com
Th
33 matches
Mail list logo
