Ronald Peterson wrote
> The existence of LATERAL seems to imply that it's possible.
The presence of LATERAL, which applies during FROM clause processing,
implies nothing about what is possible during SELECT-list processing.
This was a problem for a long time and if an easy/possible solution was
p
Thanks much. Didn't know about LATERAL. That's a solution. Seems like
the implementation could be improved though. The existence of LATERAL
seems to imply that it's possible. Why introduce more complicated syntax?
Of course the syntax applies to more situations than this one. But this
case se
Oh perfect. Thanks for the heads up! I'll be sure to voice my request one way
or another during their design phase.
--
View this message in context:
http://postgresql.nabble.com/PSQL-pgAdmin-Column-Completion-tp5832573p5832603.html
Sent from the PostgreSQL - general mailing list archive at Nab
On 12/31/2014 03:12 PM, dvlsg wrote:
True - I placed this message in general, because all the history I could find
with the pgAdmin mailing lists suggests that they /really/ don't want to
break away from the psql tab completion code and run their own. Those
messages are a few years old, however -
True - I placed this message in general, because all the history I could find
with the pgAdmin mailing lists suggests that they /really/ don't want to
break away from the psql tab completion code and run their own. Those
messages are a few years old, however - maybe things have changed.
I agree a
dvlsg writes:
> The majority of my query writing is done in pgAdmin, not psql. I do tend to
> type out the from/where/join/whatever portion of the statement before
> finishing the select portion of the statement (starting with a SELECT * and
> replacing it once the rest of the query is in place).
The majority of my query writing is done in pgAdmin, not psql. I do tend to
type out the from/where/join/whatever portion of the statement before
finishing the select portion of the statement (starting with a SELECT * and
replacing it once the rest of the query is in place). Fair enough, though --
On 12/31/2014 01:55 PM, John R Pierce wrote:
On 12/31/2014 11:56 AM, Rob Sargent wrote:
I think I see the autocompleters lining up now:
just "my" schemas
we have single schemas with 100s of tables.
I'll type the from clause first
but, the sql command is SELECT field,field FROM tables
On 12/31/2014 11:56 AM, Rob Sargent wrote:
I think I see the autocompleters lining up now:
just "my" schemas
we have single schemas with 100s of tables.
I'll type the from clause first
but, the sql command is SELECT field,field FROM tables ... so how do
you type FROM before yo
Yeah, I think that would be problematic. All other sql query applications
I've used in the past with autocomplete seem to parse the entire query and
find table references for autocompletion based on the whole query, whereas
psql seems to typically base autocomplete off of the current cursor
locatio
On 12/31/2014 12:51 PM, Tom Lane wrote:
dvlsg writes:
I have been having issues with autocomplete in pgAdmin. After some searching,
I found it was my mistake and that pgAdmin doesn't actually support column
autocompletion in select statements. I found that pgAdmin uses the
autocomplete code dir
dvlsg writes:
> I have been having issues with autocomplete in pgAdmin. After some searching,
> I found it was my mistake and that pgAdmin doesn't actually support column
> autocompletion in select statements. I found that pgAdmin uses the
> autocomplete code directly from psql's tab-complete.c, w
I have been having issues with autocomplete in pgAdmin. After some searching,
I found it was my mistake and that pgAdmin doesn't actually support column
autocompletion in select statements. I found that pgAdmin uses the
autocomplete code directly from psql's tab-complete.c, which contains these
com
The database is not crashing thankfully. We are waiting for the errors to
come back to turn up logging in the hopes of creating the reproducible set.
Mike Broers writes:
> I will do my best to provide a reproducible test case. Is there any more
> information I can supply in the meantime that would help?
Well ... just to clarify, are you suffering any crashes in your database?
Because really the "fixing incomplete split" code shouldn't get ent
Andrew Dunstan writes:
> On 12/30/2014 09:20 AM, Tom Lane wrote:
>> In one light this is certainly a bug fix, but in another it's just
>> definitional instability.
>>
>> If we'd gotten a field bug report we might well have chosen to back-patch,
>> though, and perhaps your client's complaint count
I will do my best to provide a reproducible test case. Is there any more
information I can supply in the meantime that would help?
Mike Broers writes:
> We have an ltree column (tree_path) that has a gist index
> (index_nodes_on_tree_path). This is in a 9.3.5 database. Recently errors
> started occurring in the postgres log on some updates to this table:
> fixing incomplete split in index "index_nodes_on_tree_path", block
Hello,
We have an ltree column (tree_path) that has a gist index
(index_nodes_on_tree_path). This is in a 9.3.5 database. Recently errors
started occurring in the postgres log on some updates to this table:
fixing incomplete split in index "index_nodes_on_tree_path", block 2358
STATEMENT: UPD
Hi,
On 2014-12-30 21:12:17 -0500, John Casey wrote:
>
> > What was your bdr config at this point? The error message indicates that
> it tries to
> > connect to port 5432 on localhost - but the copy was taken from
> 'main_node_ip'.
> > Perhaps you forgot to specify the ehost in the config?
>
> #
20 matches
Mail list logo
