Updated patch.
This one explicitly accepts +/- ICONST/FCONST in addition to c_expr for
both offset and limit, removing the inconsistencies mentioned
previously.
I changed the wording of the docs part a bit; does that look better? or
worse?
Old behavior:
select 1 offset +1 rows; -- ERROR: synta
construct_md_array works for me, thanks for inputs!
2018-05-17 13:42 GMT-07:00 Andrew Gierth :
> > "Charles" == Charles Cui writes:
>
> Charles> I have the requirements to return a bytea array for some
> Charles> functions in pg_thrift plugin.
>
> If you mean you want the return value to b
> "Tom" == Tom Lane writes:
>> I'm +1 for backpatching it. It may be operating as designed by
>> PeterE ten years ago, but it's not operating as designed by the SQL
>> standard.
Tom> By that argument, *anyplace* where we're missing a SQL-spec
Tom> feature is a back-patchable bug. I don'
> "Tom" == Tom Lane writes:
Tom> Also, why'd you back off "must write" to "should write" in the docs?
Tom> This doesn't make the parens any more optional than before.
Currently, the requirement for parens is inconsistent - FETCH FIRST
wants them for absolutely anything that's not a literal
Hi all,
This is basically a new thread after what has been discussed for
pg_controldata with its error handling for read():
https://www.postgresql.org/message-id/CABUevEx8ZRV5Ut_FvP2etXiQppx3xVzm7oOaV3AcdHxX81Yt8Q%40mail.gmail.com
While reviewing the core code, I have noticed similar weird error
On Sat, May 19, 2018 at 07:41:10PM -0400, Tom Lane wrote:
> Vik Fearing writes:
>> I'm +1 for backpatching it. It may be operating as designed by PeterE
>> ten years ago, but it's not operating as designed by the SQL standard.
>
> By that argument, *anyplace* where we're missing a SQL-spec featu
Vik Fearing writes:
> On 20/05/18 00:57, Tom Lane wrote:
>> Also, why'd you back off "must write" to "should write" in the docs?
>> This doesn't make the parens any more optional than before.
> It certainly does. It allows this now:
> PREPARE foo AS TABLE bar FETCH FIRST $1 ROWS ONLY;
No, it ma
On 20/05/18 01:27, Vik Fearing wrote:
>> Also, why'd you back off "must write" to "should write" in the docs?
>> This doesn't make the parens any more optional than before.
>> It certainly does. It allows this now:
>
> PREPARE foo AS TABLE bar FETCH FIRST $1 ROWS ONLY;
Please disregard this comm
On 20/05/18 00:57, Tom Lane wrote:
> Andrew Gierth writes:
>> Attached is a draft patch for fixing that, which additionally fixes the
>> ugly wart that OFFSET ROW/ROWS and FETCH FIRST [] ROW/ROWS ONLY
>> had very different productions for ; both now accept c_expr there.
>
> LGTM, except please s
Andrew Gierth writes:
> Attached is a draft patch for fixing that, which additionally fixes the
> ugly wart that OFFSET ROW/ROWS and FETCH FIRST [] ROW/ROWS ONLY
> had very different productions for ; both now accept c_expr there.
LGTM, except please s/presense/presence/ in grammar comment.
Also
Per bug #15200, our support for sql2008 FETCH FIRST syntax is incomplete
to the extent that it should be regarded as a bug; the spec quite
clearly allows parameters/host variables in addition to constants, but
we don't.
Attached is a draft patch for fixing that, which additionally fixes the
ugly w
I noticed while poking at the recent ecpg unpleasantness that some
of my older critters were warning about use of %lf conversions in
printf. Looking into it, I find that current POSIX says the "l"
is a no-op, while SUSv2 says it's undefined. I think this usage
got into our code as a result of peo
John Naylor writes:
> Long story short: It expects an array of paths, but will die if it
> can't find the symbol in the first path. Arguably it's a bug, but
> since the original use case for multiple paths is long gone anyway, it
> might never occur in practice. The attached patch changes it to ex
Our configure script goes to considerable lengths to try to identify
what printf width modifier to use for int64 values. In particular
see PGAC_FUNC_SNPRINTF_LONG_LONG_INT_MODIFIER, which claims
# MinGW uses '%I64d', though gcc throws a warning with -Wall,
# while '%lld' doesn't generate a warnin
On 19 May 2018 at 01:13, Stephen Frost wrote:
>
> I'm not entirely sure about the varlena suggestion, seems like that
> would change a great deal more code and be slower, though perhaps not
> enough to matter; it's not like our aclitem arrays are exactly optimized
> for speed today.
I don't actua
On Fri, May 18, 2018 at 8:13 PM, Stephen Frost wrote:
> I'm not a big fan of it- what happens when we introduce something else
> which would seem like it'd fall under 'maintain' but provides some
> capability that maybe it wouldn't be good for users who could only run
> the above commands to have?
On Fri, May 18, 2018 at 09:30:22AM -0400, Bruce Momjian wrote:
> Good work, but I think the existance of both scram_channel_binding and
> channel_binding_mode in libpq is confusing. I am thinking we should
> have one channel binding parameter that can take values "prefer",
> "tls-unique", "tls-ser
On Fri, May 18, 2018 at 10:22:29AM -0400, Tom Lane wrote:
> Only comment I have is that I think there's similar shortcuts in a lot
> of places :-(
Yeah. A quick lookup is showing me one in xlog.c (XLOG_BLCKSZ) and one
in pg_rewind. (Spotted roughly 392 places to look at in all the core
code). L
I wrote [1]:
> On 4/26/18, Tom Lane wrote:
>> if I counted correctly. (Array entries should be ignored for this
>> purpose; maybe we'll autogenerate them someday.)
>
> Hmm, that wouldn't be too hard. Add a new metadata field called
> 'array_type_oid', then if it finds such an OID, teach genbki.p
Long story short: It expects an array of paths, but will die if it
can't find the symbol in the first path. Arguably it's a bug, but
since the original use case for multiple paths is long gone anyway, it
might never occur in practice. The attached patch changes it to expect
a single path.
Also att
20 matches
Mail list logo
