On 4 May 2016 at 13:23, Peter Eisentraut
wrote:
> On 5/4/16 3:21 AM, Dean Rasheed wrote:
>> Well, appendStringLiteralAH() takes both, so that sets a precedent.
> Works for me. Could you supply an updated patch with a static function
> instead of a macro? Then I think this is good to go.
>
> (bon
On 5/4/16 3:21 AM, Dean Rasheed wrote:
Well, appendStringLiteralAH() takes both, so that sets a precedent.
Works for me. Could you supply an updated patch with a static function
instead of a macro? Then I think this is good to go.
(bonus points for some tests)
--
Peter Eisentraut
On 4 May 2016 at 01:35, Peter Eisentraut
wrote:
> On 5/3/16 3:10 PM, Dean Rasheed wrote:
>> On 3 May 2016 at 16:52, Peter Eisentraut
>>>
>>> I would change appendReloptionsArrayAH() to a function and keep AH as the
>>> first argument (similar to other functions that take such a handle).
>>
>> I ca
On 5/3/16 3:10 PM, Dean Rasheed wrote:
On 3 May 2016 at 16:52, Peter Eisentraut
wrote:
I would change appendReloptionsArrayAH() to a function and keep AH as the
first argument (similar to other functions that take such a handle).
I can understand changing it to a function, but I don't think
On 3 May 2016 at 16:52, Peter Eisentraut
wrote:
> I would change appendReloptionsArrayAH() to a function and keep AH as the
> first argument (similar to other functions that take such a handle).
I can understand changing it to a function, but I don't think AH
should be the first argument. All oth
On 5/2/16 8:53 AM, Dean Rasheed wrote:
Here are updated patches doing that --- the first moves
fmtReloptionsArray() from pg_dump.c to fe_utils/string_utils.c so that
it can be shared by pg_dump and psql, and renames it to
appendReloptionsArray(). The second patch fixes the actual psql bug.
This
On 27 April 2016 at 08:36, Dean Rasheed wrote:
> Here is a rough patch based on the way pg_dump handles this. It still
> needs a bit of polishing -- in particular I think fmtReloptionsArray()
> (copied from pg_dump) should probably be moved to string_utils.c so
> that it can be shared between pg_d
[Looking back over old threads]
On 22 July 2015 at 22:00, Dean Rasheed wrote:
> This appears to be missing support for view options (WITH CHECK OPTION
> and security_barrier), so editing a view with either of those options
> will cause them to be stripped off.
It seems like this issue was never
On 22 July 2015 at 21:37, Tom Lane wrote:
> Dean Rasheed writes:
>> On 3 July 2015 at 20:50, Tom Lane wrote:
>>> Oh? If that were true, pg_dump wouldn't work on such views. It is kind
>>> of a PITA for this purpose that it doesn't include the CREATE text for
>>> you, but we're surely not chang
Dean Rasheed writes:
> On 3 July 2015 at 20:50, Tom Lane wrote:
>> Oh? If that were true, pg_dump wouldn't work on such views. It is kind
>> of a PITA for this purpose that it doesn't include the CREATE text for
>> you, but we're surely not changing that behavior now.
> This appears to be miss
On 3 July 2015 at 20:50, Tom Lane wrote:
> Petr Korobeinikov writes:
>> Fixed. Now both \ev and \sv numbering lines starting with "1". New version
>> attached.
>
> Applied with a fair amount of mostly-cosmetic adjustment.
>
>> As I've already noticed that pg_get_viewdef() does not support full s
Petr Korobeinikov writes:
> Fixed. Now both \ev and \sv numbering lines starting with "1". New version
> attached.
Applied with a fair amount of mostly-cosmetic adjustment.
> As I've already noticed that pg_get_viewdef() does not support full syntax
> of creating or replacing views.
Oh? If th
пт, 3 июля 2015 г. в 19:30, Tom Lane :
> So AFAICS, \ev and \sv should just number lines straightforwardly, with
> "1" being the first line of the CREATE command text. Am I missing
> something?
>
Fixed. Now both \ev and \sv numbering lines starting with "1". New version
attached.
As I've alrea
Jeevan Chalke writes:
> Patch looks excellent now. No issues.
> Found a typo which I have fixed in the attached patch.
Starting to look at this ...
The business with numbering lines from SELECT seems to me to be completely
nonsensical. In the first place, it fails to allow for views containing
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Patch looks good to pass to committer.
The new status of thi
Hi
Patch looks excellent now. No issues.
Found a typo which I have fixed in the attached patch.
Thanks
--
Jeevan B Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/p
> 1.
> make failed with docs
>
Fixed.
> 2.
> > \ev vw1 3
>
> This syntax is supported. But documentation only says:
> \ev [ viewname ]
> Missing optional line_number clause
>
Fixed. Documented.
3.
> > strip_lineno_from_objdesc(char *func)
>
> Can we have parameter name as obj instead of func.
>
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, failed
I have reviewed this patch. Most of the code is just rearrang
Just a merge after pgindent run (807b9e0dff663c5da875af7907a5106c0ff90673).
psql-ev-sv-support-v3.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
This version contains one little change.
In order to be consistent with “\d+ viewname” it uses pg_get_viewdef(oid, /*
pretty */ true) to produce “pretty” output (without additional parentheses).
psql-ev-sv-support-v2.diff
Description: Binary data
> On 05 May 2015, at 16:42, Robert Haas wrote:
On Mon, May 4, 2015 at 5:21 AM, Petr Korobeinikov
wrote:
> I'm proposing to add two new subcommands in psql:
> 1. \ev viewname - edit view definition with external editor (like \ef for
> function)
> 2. \sv viewname - show view definition (like \sf for function, for
> consistency)
Sounds nice. Ma
On Mon, May 4, 2015 at 6:26 AM, Pavel Stehule
wrote:
>
>
> 2015-05-04 11:21 GMT+02:00 Petr Korobeinikov :
>
>> Hackers!
>>
>> I'm proposing to add two new subcommands in psql:
>> 1. \ev viewname - edit view definition with external editor (like \ef for
>> function)
>> 2. \sv viewname - show view
2015-05-04 11:21 GMT+02:00 Petr Korobeinikov :
> Hackers!
>
> I'm proposing to add two new subcommands in psql:
> 1. \ev viewname - edit view definition with external editor (like \ef for
> function)
> 2. \sv viewname - show view definition (like \sf for function, for
> consistency)
>
+1
Pavel
Hackers!
I'm proposing to add two new subcommands in psql:
1. \ev viewname - edit view definition with external editor (like \ef for
function)
2. \sv viewname - show view definition (like \sf for function, for
consistency)
What's inside:
1. review-ready implementation of \ev and \sv psql subcomma
24 matches
Mail list logo
