Feature: supporting optional arguments in named/favourite queries?
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
Línea de trabajo
Comienza rastreando el manejo existente de \n NAME ARGS... para consultas con nombre y favoritas en pgspecial. Resuelve la sintaxis de los argumentos opcionales y el comportamiento ante valores faltantes, incluidos los parámetros agregados; después, añade cobertura para invocaciones con y sin argumentos opcionales, preservando los fallos existentes para los argumentos requeridos.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Hopefully this is the right place, since as best I can tell, the code for \n NAME ARGS... as provided by pgcli actually lives in here.
It would be convenient if there was a way to specify optional arguments to be replaced in a named query, to allow something like:
\ns opt-args select * from some_table where ($?1 is null or some_field like '%$?1%')
so it could be invoked as either \n opt-args with no args to just query everything, or if \n opt-args somevalue to filter to only things matching that argument, without needing to have different queries with/without args (and remembering which you want to use at the time)
I've invented the $?<num> format in the above example which doesn't currently exist. That allows it to be distinguished from normal arguments as they are now, to avoid breaking existing behaviour of the invocation failing if there are unreplaced parameters left.
I'm currently imagining that the optional arg would just be substituted with the value NULL if not present, although a case could be made for a more bash-like ${VAR:-DEFAULT} to allow arbitrary replacement values if not provided.
It might make sense to allow optional aggregated params as well, although not sure if they should expand to an empty list, or also to NULL.
I think I can probably cobble up a PR if there's any interest, but figured it might be wise to check first, and maybe bikeshed the syntax before ploughing ahead 😄
- Lenguaje dominante
- Python
- Estrellas
- 86
- Forks
- 54
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de dbcli/pgspecial
-
Dificultad 3/5 1-2 días Aptitud para principiantes 40/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
-
Add \crosstabviewAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
Todos los issues de dbcli/pgspecial
Issues similares
-
comp/cli P3 type/security
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
NousResearch/hermes-agent#141420 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
vendor-pitch
Dificultad 2/5 1-3 horas Aptitud para principiantes 87/100
Los mantenedores suelen responder en 1 día
-
bug llm p2
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
amd/gaia#5379 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
New tool: ZIPZAX Python Notebook StudioPosiblemente ocupada @github-actions la tomó hoy. Abiertosubmission triage
Dificultad 1/5 Menos de una hora Aptitud para principiantes 68/100
kausalflow/tools#226 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100