Michael Paquier writes:
> On Sat, Jan 2, 2016 at 4:06 AM, Tom Lane wrote:
>> The grammar fixes seem like a good thing to do in the long run, too,
>> but there's little need to risk back-patching it since accepting
>> col_name_keywords without quoting would be mostly a convenience issue.
> A diff
Tom Lane wrote:
> But some experimentation suggests that we could
> fix that by subdividing col_name_keyword into two categories, one being
> the keywords that can also be type names (BIGINT, BIT, etc) and one
> being those that can't (BETWEEN, COALESCE, etc). Everywhere
> col_name_keyword is use
On 1 January 2016 at 19:06, Tom Lane wrote:
> I wrote:
> > Now, one line of thought here is that flatten_reloptions() is out of its
> > mind to not be worrying about quoting the reloption values. And perhaps
> > it is, but I think if we go that direction, we may be fighting similar
> > fires for
On Sat, Jan 2, 2016 at 4:06 AM, Tom Lane wrote:
> I wrote:
>> Now, one line of thought here is that flatten_reloptions() is out of its
>> mind to not be worrying about quoting the reloption values. And perhaps
>> it is, but I think if we go that direction, we may be fighting similar
>> fires for
I wrote:
> Now, one line of thought here is that flatten_reloptions() is out of its
> mind to not be worrying about quoting the reloption values. And perhaps
> it is, but I think if we go that direction, we may be fighting similar
> fires for awhile to come. psql's describe.c, for example, doesn'
I did a bit of initial poking at the problem complained of in bug #13840,
namely that if you use "none" as the value of a reloption, you get a
syntax error when trying to reload a dump containing the table or index
declaration. The submitter blames this on pg_dump but it is surely not
pg_dump's fa
