Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Feature: supporting optional arguments in named/favourite queries?

Đang mở
  • Có gì không ổn?
#143 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
postgresql, python, sql
Lĩnh vực
cli, databases

Hướng nghiên cứu

Bắt đầu bằng cách lần theo cách xử lý hiện có của \n NAME ARGS... đối với các truy vấn được đặt tên và truy vấn yêu thích trong pgspecial. Xác định cú pháp đối số tùy chọn và hành vi khi thiếu giá trị, bao gồm cả các tham số được tổng hợp, sau đó bổ sung phạm vi kiểm thử cho các lần gọi có và không có đối số tùy chọn, đồng thời giữ nguyên các lỗi hiện có đối với đối số bắt buộc.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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 😄

Ngôn ngữ chính
Python
Star
86
Fork
54
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của dbcli/pgspecial

Tất cả issue của dbcli/pgspecial

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.