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
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
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
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 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 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
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
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
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
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
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
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
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
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 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
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
> "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
> "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'
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
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
20 matches
Mail list logo
